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SUPPORTING EFFECTIVE LIBRARY MANAGEMENT FOR OVER TWENTY YEARS 


Committed to assisting research and academic libraries in the continuous improvement of management 
systems, OLMS has worked since 1970 to gather and disseminate the best practices for library needs. As 
part of its committment, OLMS maintains an active publications program best known for its SPEC Kits. 
Through the OLMS Collaborative Research/Writing Program, librarians work with ARL staff to design 
SPEC surveys and write publications. Originally established as an information source for ARL member 
libraries, the SPEC series has grown to serve the needs of the library community worldwide. 


Wuat Are SPEC Kits? 


Published six times per year, SPEC Kits contain the most valuable, up-to-date information on the latest 
issues of concern to libraries and librarians today. They are the result of a systematic survey of ARL member 
libraries on a particular topic related to current practice in the field. Each SPEC Kit contains an executive 
summary of the survey results (previously printed as the SPEC Flyer); survey questions with tallies and 
selected comments; the best representative documents from survey participants, such as policies, procedures, 
handbooks, guidelines, websites, records, brochures, and statements; and a selected reading list—both in 
print and online sources—containing the most current literature available on the topic for further study. 


SUBSCRIBE TO SPEC 


Subscribers tell us that the information contained in SPEC Kits is valuable to a variety of users, both 
inside and outside the library. SPEC purchasers use the documentation found in SPEC Kits as a point of 
departure for research and problem solving because they lend immediate authority to proposals and set 
standards for designing programs or writing procedure statements. SPEC Kits also function as an important 
reference tool for library administrators, staff, students, and professionals in allied disciplines who may not 


‘ have access to this kind of information. 
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Information on SPEC and other OLMS products and services can be found on the ARL website at <http: / 
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User Authentication 


Executive Summary 


Introduction 

Until the advent of the World Wide Web and the 
concomitant development of global computer 
networks, most research libraries could provide 
access to their resources with few concerns about the 
status of those who sought the information, or 
concerns that the information was restricted to 
certain classes of users. Developments in computer 
technologies have irrevocably altered library 
operations, and it is now the exceptional library that 
has not in some way responded to the challenges of 
authenticating and authorizing its users, particularly 
those users needing to access the library’s systems 
and networked information resources from remote 
locations. Furthermore, licenses for networked 
information resources increasingly require 
authentication controls and need to specify different 
levels of authorization. 

Authentication and authorization are complex 
access management processes that involve the 
verification of the identity and status of the user, the 
ways in which IP ranges are limited, the processes by 
which information technology support is handled, 
and the systems by which authentication 
information and authorization are maintained. 

This SPEC survey is designed to examine the 
systems that research libraries use to authenticate 
and authorize the users of their online networked 
information resources. For the purposes of this 
survey, authentication is defined as the process of 
determining whether someone or something is, in 
fact, who or what he declares himself to be. 
Authorization is the process of giving someone 
permission to do or have something, including 
privileges of use, such as access to file directories, 
amount of allocated storage space, access to licensed 
electronic resources, and so forth. Networked 
information resources are defined as electronically 


accessible information resources (e.g., library or 
academically developed databases, university 
databases, commercial databases, full-text services, 
e-journals, etc.) funded or enabled by the library, 
which are made available to authorized users 
through an intentional and systematic network 
(LAN, WAN, dial-in, etc.). 

This survey was distributed to the 121 ARL 
member libraries in spring 2001. Fifty-two libraries 
(43%) responded to the survey. 


Authentication 

Fifty-one of the responding institutions (98%) 
stated that they authenticated their users in some 
way. The one library reporting no authentication 
apparently limits by IP, has a proxy server, and offers 
remote access services to library resources through a 
modem pool. Therefore, all of the responding 
libraries authenticate users of networked resources. 

In selecting user categories for authentication, 48 
respondents (96%) authenticate staff, and 46 (92%) 
authenticate their undergraduate students, graduate 
students, and faculty. Seven libraries (14%) 
authenticate alumni and local community members, 
although their access to the library’s networked 
electronic resources is apparently much reduced. 
Fourteen respondents (28%) report that they 
authenticate other categories, providing access to 
groups such as Friends of the Library, extension 
faculty and students, selected department-sponsored 
guest accounts, university affiliates, affiliated 
institutions, and external clients, including 
international clients. 

There were 49 responses (96%) to the question 
about the number of networked information 
resources made available to authenticated users, but 
the numbers varied enormously, from 1 to 23,806. 


That these numbers are so disparate almost certainly 
I 


demonstrates that there is no agreement on the unit 
of analysis for measuring “networked information 
resources.” A simple example will suffice in showing 
the nature of the problem: does JSTOR count as a 
single networked information resource, or is it the 
sum of its subscription modules, or is it the sum of 
the journal contents? And, if the latter, how are title 
changes treated? This problem is only exacerbated 
when one considers the number and variety of 
networked electronic resources potentially available 
to ARL member libraries. 

Access Management Systems 

There was equal divagation in the responses on 
the type of access management system used to 
authenticate users of networked information 
resources, although in this case the disparity appears 
to be the result of respondents using multiple 
systems. For example, 42 of the 51 responding 
libraries (82%) report using IP addresses to 
authenticate users of at least some portion of their 
networked electronic resources, while an _ 
overlapping 40 (78%) report the use of password and 
user ID. There is similar overlap among and within 
the other types of systems. (See question 4 in the 
Survey Results section for a chart of the types of 
systems used.) 

Surprisingly few libraries (10, or 20%) use the ILS 
to authenticate patrons, and only four (8%) use a 
non-ILS gateway, such as OCLC’s WebZ. Based ona 
review of the literature and websites, the number of 
libraries that use Public Key Infrastructure (PKI) is 
also unexpectedly small. Since only three libraries 
(6%) claim that they have enabled this scheme to 
authenticate patrons, perhaps PKI is as yet more 
discussed than implemented. 

All together, 46 respondents report using some 
kind of proxy server. These libraries apparently are 
migrating from mechanical proxy systems (pac files) 
to application-level proxy servers or rewriters (such 
as EZproxy). Twenty-six libraries report using a 
mechanical proxy system, whereas 12 use an 
application-level rewriter. Two libraries use both. 
Fifteen respondents (33%) use EZproxy as the proxy 
server software, almost twice as many as use Apache 
(9 respondents or 20%), Squid (8, or 17%), or Web 
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Access Management (III) (6, or 13%). Only three 
respondents use Netscape Iplanet Proxy, and one 
uses Microsoft Proxy. A small number of institutions 
are using homegrown or custom solutions. Of the 42 
libraries that rely upon IP authentication, only four 
have neither a proxy server nor a modem pool, while 
only two still rely upon a dial-in modem pool 
exclusively for off-campus access. 

Survey respondents were asked which database 
of patron information is used to verify eligible users. 
Again, it is evident that multiple systems are in use 
at many institutions. In the majority of instances (28 
responses or 55%) some portion of the authentication 
system checks against a dynamic patron load or 
circulation patron record database with the ILS. 
Fewer institutions (20, or 39%) have a system that 
checks against a dynamic institutional personnel 
database. An equal number (14, or 28%) use a system 
check against a flat file extracted from the ILS or a 
system check against a separately created database 
of eligible users. Only seven (14%) use a system 
check against a flat file extracted from the 
institutional personnel database. Five respondents 
(10%) use other solutions, including a Virtual 
Personal Network and personal certificates. 


Authorization 

What services are being authorized after 
authentication? The access provided by credential- 
based (passwords, certificates, etc.) systems is widely 
distributed. At 35 institutions (69%), authenticated 
users can access their personal circulation record, 
while at 33 (65%) users can request interlibrary loans 
and document delivery and use e-mail. Other 
accessible services include holds and recalls on 
books (31 institutions or 61%), course registration 
information (29, or 57%), databases (28, or 55%), and 
both course reserve materials and file space on the 
network server (25, or 49%). Numbers were lower 
for accessing financial records and computer labs 
(21, or 41%) and lower still for accessing e-books and 
e-journals (20, or 39%). The figures continued to 
drop for accessing the library OPAC (19, or 37%), 
distance education courses (18, or 35%), and 
transcripts (17, or 33%). Only seven institutions 
(14%) use credential-based systems to provide access 
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to photocopy machines, dining facilities, and 
groupware. 

The distribution of services provided by proxy 
systems and IP filtering is almost identical. The 
majority of institutions that use a proxy server 
provide access to databases (41, or 80%), e-journals 
(40, or 78%), and e-books (36, or 71%). Fourteen 
(27%) provide access to course reserve materials, and 
11 (22%) to the library OPAC. There are few uses of 
the proxy server for other purposes, although six 
respondents (12%) report using it for distance 
education courses. 


User Privacy 

Questions of confidentiality and privacy policy 
are important to any web-based authentication 
system. Although this survey did not specifically 
inquire about privacy policies, it surveyed 
respondents about how user information is tied to 
the respective search session and whether such 
information is archived. Thirty-two of 49 
respondents (65%) provide anonymous access, in 
which each session is anonymous and repeat users 
cannot be identified. Twenty-four (49%) provide 
identified access, in which actual identities are 
associated only with sessions, and 12 (25%) provide 
pseudonymous access, in which repeat users can be 
identified, but the identity of a specific user cannot 
be determined. These responses appear to be closely 
allied with the American Library Association (ALA) 
Policy Concerning Confidentiality of Personally 
Identifiable Information about Library Users. This policy 
states in part that, “Confidentiality extends to 
‘information sought or received, and materials 
consulted, borrowed or acquired,’ and includes 
database search records, reference interviews, 
circulation records, interlibrary loan records, and 
other personally identifiable uses of library 
materials, facilities, or services.” Nevertheless, ten 
respondents (20%) archive identified access data and 
eight (16%) provide pseudonymous access with 
demographic information that does not provide 
actual identities. The ALA Policy on Confidentiality of 
Library Records strongly recommends that, 
“Responsible officers of each library, cooperative 
system, and consortium in the United States 
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formally adopt a policy which specifically recognizes 
its circulation records and other records identifying 
the name of library users to be confidential in 
nature.” It appears that most libraries address this 
issue by refusing to store ID information with 
session data. 


System Management 

Who does the work of building and maintaining 
the authentication system? In general, much of the 
work is done within the library. Central library 
information technology (IT) staff manage the 
authentication and authorization systems in 46 of the 
responding institutions (90%). Institution or campus- 
wide IT staff manage them for 37 (73%) of the 
respondents and the vendor of the networked 
information resource manages authentication for 25 
(49%). One respondent wrote that campus IT 
handles e-mail, registration, and distance education; 
the vendor handles IP authentication for e-journals, 
e-books, and online databases; and the library 
handles the other resources. This is a very traditional 
arrangement. 

Question 9 asked how many IP-filtered resources 
are managed at the vendor, consortium, institution, 
or other level. The data again illustrate the difficulty 
of counting networked information resources with 
responses ranging from zero to more than 10,000. A 
general impression is that the vendor most often 
handles IP-based access restrictions to library 
resources. 

At the 26 institutions that manage access by an 
ILS capable of accessing databases through Z39.50 
(z-client), survey results indicate a fairly equal 
distribution across ILS vendors. Endeavor and III are 
each used by five of the 26 respondents (19%), SIRSI 
is used by four (15%), and DRA is used by three 
(12%). Six respondents (23%) use other vendors, 
which included Geac Advance, CDL and Melvy], 
and EpixTech Horizon. 

When access is managed by passwords and user 
IDs, passwords are typically randomly generated 
and are not expired on a regular schedule. The 40 
responses to the question on how often passwords 
are expired showed evident confusion about the 
process. In several instances, there was no 


mechanism in place to expire passwords, and they 
thus did not expire or expired “rarely” or with “no 
set period,” although one respondent indicated that 
this was under review. Several respondents 
indicated that passwords expired at a fixed time—at 
the end of each quarter, semester, term, or annual 
session—but several also indicated that expirations 
were dependent on the status of the individual, and 
that expirations occurred when the person 
graduated or left the University. 

There are a variety of schemes in place to prevent 
the hijacking of user IDs and passwords by 
unauthorized persons, including SSL and IP 
restriction to webpages that list passwords. There are 
also various methods for authentication when the 
initial user ID and password are assigned: for 
example, in-person registration with photo ID. 
Nonetheless, there appear to be no technical schemes 
for limiting the distribution of user IDs and 
passwords by authorized users to unauthorized 
users. Most institutions that recognized the existence 
of this problem have a use policy or honor system. 

There are few respondents who manage access 
through a library gateway such as WebZ. Four of the 
13 respondents (31%) use OCLC products such as 
WebZ and SiteSearch. The others use a webscript 
from OCLC, DRA Web2, VTLS, WebVoyage, or 
Voyager. Slightly fewer than half of this group has a 
gateway that provides access to both Z39.50 and 
non-Z39.50 resources. Only five respondents report 
that they manage access by digital certificates. Two 
of these use Kerberos and two use VeriSign. 

The future of access management systems 
appears to indicate some turmoil. Of 47 respondents, 
almost half (22, or 47%) indicated that they plan to 
switch to a different access management system 
within the next two years. The responses are 
heterogeneous and most respondents seem still to be 
in the planning stage. The new systems most often 
mentioned are EZproxy, digital certificates, and 
LDAP. Several respondents indicated that they had 
identified nothing, but that evaluations were being 
done. These changes would bear reexamination. 


Conclusions 
One of the inescapable conclusions to emerge 
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from this survey is that research libraries do not 
appear to possess a common standard or a common 
vocabulary that can be used for measuring, 
describing, and communicating their holdings of 
networked information resources. This is evident 
from the disparate responses to the deceptively 
simple question involving the number of networked 
information resources made available to 
authenticated users. That the responses are so 
disparate certainly demonstrates that there is no 
agreement on the standard unit of analysis for 
measuring the concept of “networked information 
resource.” Libraries that can provide statistics on 
books and serials have more difficulty counting 
electronic resources.’ 

Another conclusion emerges directly from the 
library responses to the application-level proxy 
rewriter. Those libraries that have implemented an 
application-level proxy rewriter are able to serve 
additional resources through it, offering more 
resources than those libraries that do not use the 
application-level proxy rewriter. The application- 
level proxy server occupies a more central position 
in the authentication system than mechanical proxy 
servers. Although relatively few users rely upon a 
credential-based system to provide network access 
and authentication, an optimum system might 
integrate a credential-based system and the 
application-level proxy rewriter, eliminating the 
need for a gateway access management system. 

Apparently, the Z39.50 standard no longer plays a 
significant role in the way research libraries provide 
access to their networked information resources. 
When only 20% of the responding libraries use a 
Z39.50 capable ILS for authentication and when that 
authentication represents only 6% of authenticated 
usage in those libraries, it is safe to say that the 
standard is less relevant than it once was and is no 
longer the future for libraries in meeting the 
information needs of their users. 

Confidentiality of library records appears to be 
addressed by the deletion of ID data from session 
information. Most libraries are addressing the ALA 
Policy on Confidentiality of Library Records by 
establishing a system where the ID data cannot be 
retrieved because they are not archived. We think 
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this phenomenon deserves further attention, and 
speculate that the ID data are in fact valuable and 
should be retained. It is perhaps a lack of trust in 
policies or a lack of confidence in technical security 
that has encouraged so many institutions to remove 
this data. , 

There was little homogeneity in the 37 responses 
to Question 14, which involved security measures to 
insure that passwords and IDs are not distributed 
inappropriately. Some respondents use manual 
(personal) ID checks and verifications; others 
attempt to create secure pages with special logins 
and PINs; still others attempt to link to databases 
(payroll, registration, human resources) and to verify 
validity with other systems before establishing an 
account. Passwords likewise are distributed in all 
possible ways, with some respondents offering 
immediate validation while others send personal 
mail containing the passwords. Once the passwords 
are distributed, most institutions rely upon honor 
codes and signed use agreements to limit further 
distribution of the passwords by authorized users to 
unauthorized users. That there is such little 
agreement in the ways in which authorized and 
unauthorized users can be determined would seem 
to necessitate additional research and further study 
of this subject. 

Finally, there were a number of comments 
concerning the heterogeneity of the authentication 
systems. “Extremely heterogeneous network,” 
“There are a lot of different authentication and 
authorization systems all around campus,” 
“Question 4 was difficulty to answer since we often 
use a combination of methods for our authentication 
routines.” And most tellingly, “We have three layers 
of authentication.” There are both layered, integrated 
systems and those with different authentication 
systems for different services. The complicated 
authentication environment is a difficult picture to 
survey. It does seem clear that, at many libraries, 
system analysis is being applied to authentication 
schema, and efforts are being made to integrate 
disparate authentication systems into a layered or 
sequential approach. 


1Editor’s note: The E-Metrics project, one of the 
ARL New Measures Initiatives, is an effort to explore 
the feasibility of defining and collecting data on the 
use and value of electronic resources. Information 
about the project is available on the ARL website at 
<http://www.arl.org/stats /newmeas /emetrics/ 
index.html>. 
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User Authentication 
Survey Results 


Until the advent of the World Wide Web and the concomitant development of global computer networks, 
most research libraries could provide access to their resources with few concerns about the status of those 
who sought the information or concerns that the information was restricted to certain classes of users. 
Developments in computer technologies have irrevocably altered library operations, and it is now the 
exceptional library that has not in some way responded to the challenges of authenticating and authorizing 
its users, particularly those users needing to access the library's systems and networked information 
resources from remote locations. Furthermore, licenses for networked information resources increasingly 
require authentication controls, as well as setting levels of authorization. 


Authentication and authorization are complex access management processes that involve a verification of 
the identity and status of the user, the ways in which IP ranges are limited, the processes by which 
information technology support is handled, and the systems by which authentication information and 
authorization levels are maintained. 


This SPEC survey is designed to examine the systems research libraries use to authenticate and authorize the 
users of their online networked information resources. For the purposes of this survey, authentication is 
defined as the process of determining whether someone or something is, in fact, who or what he or she is 
declared to be. Authorization is the process of giving someone permission to do or have something, 
including privileges of use (such as access to file directories, amount of allocated storage space, access to 
licensed electronic resources, and so forth). Networked information resources are defined as electronically 
accessible information resources (e.g., library or academically developed databases, university databases, 
commercial databases, full-text services, e-journals, etc.) funded or enabled by the library, which are made 
available to authorized users through an intentional and systematic network (LAN, WAN, dial-in, etc.). 


This survey was designed by Terry Plum, Assistant Professor, Simmons Graduate School of Library and 
Information Science, and Richard Bleiler, Humanities Reference Librarian, University of Connecticut. 


Please submit this survey and send the requested documentation by July 6, 2001. As always, individual 
responses to the survey will be treated confidentially. 


Note: Fifty-two of the 121 ARL member libraries (43%) responded to the survey. 
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Background 
1. Does your institution authenticate users of networked information resources? (n=52) 


Yes 51 98% 


No 1 2% 

Authentication 

2. Which user categories may be authenticated? Check all that apply. (n=50) 
Staff 48 96% 
Undergraduate students 46 92% 
Graduate students 46 92% 
Faculty 46 92% 
Any onsite user 15 30% 
Consortium members 7 14% 
Local community members 7 14% 
Alumni 5 10% 
Other 14 28% 


Please explain 

Other categories include: Friends of the Library, extension faculty and students, selected 
department-sponsored guest accounts, university affiliates, affiliated institutions, and external 
clients. 


3. How many networked information resources are made available to authenticated users? (n=49) 


Responses ranged from 1 to nearly 24,000. Clearly, there is no agreement on the unit of measure for 
these resources. 


5 


4. What type of access management system does your institution use to authenticate users of 
networked information resources? Check all systems that are used. Indicate the number of resources 
available through each system used and the percent of total use each system receives. 
(Approximations are acceptable.) Also, check each system for which usage statistics are gathered 
and maintained. (n=51) 


% of Total Use Statistics 


nipeoheym | sea | median | n_| gathered 
Credential-based System l45 | | 


Smart Card 


Mechanical proxy (Pacfile) 59 
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IP with modem pool 
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5. How does the authentication system verify eligible users? (n=51) 

System checks against a dynamic database within ILS 28 55% 
System checks against a dynamic institutional personnel database 20 39% 
System checks against a flat file extracted from ILS 14 28% 
System checks against a separately created database of eligible users 14-28% 
System checks against a flat file extracted from the institutional personnel 

database 7 14% 
Other 5 10% 


Please explain 
Other responses include: Virtual Personal Network (VPN) and personal certificates. 
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Authorization 


6. Which networked resources and services may an authenticated user access? Check all resources and 
services that apply for each type of authentication system. (n=51) 


SN bard FA 
System System Filter Gatewa System 


Financial records 


Computer labs 


Please explain 
Credential-based systems are also used to provide access to printers and staff webpages. 
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User Privacy 


7. How does the access management system handle user privacy? (n=49) 
Anonymous access (Each session is anonymous. Repeat users 32 65% 
cannot be identified.) 
Identified access (Actual identities are associated only with 24 49% 
sessions.) 
Pseudonymous access (Repeat users can be identified, but the 12 25% 


identity of a user cannot be determined.) 


Identified access and data are archived 10 20% 
Pseudonymous access with demographic identification 8 16% 
(Demographic characteristics of users can be determined, but 
not actual identities.) 
Other 1 2% 


Please explain 


Various authentication systems log limited user session information. Details of user activity are 


not kept. 


System Management 


8. Who manages the authentication and authorization system(s)? Check all that apply. (n=51) 


Central library information technology (IT) staff 
Institution or campus-wide IT 
Vendor of networked information resource 
Consortium IT 
Branch or regional library IT 
Outsourced to a noninstitutional IT group 
Other 

Please explain 


46 90% 
37 73% 
25 49% 
5 9% 
2 4% 
0 0% 
4 8 % oO 


The other responses explained the overlap in management. 
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System Specific Questions 
If access to networked information resources is managed by IP: 
2 Now many available resources are managed at the: (n=37) 
Vendor level 
Consortium level 
Institution level 
Other 
As with Question 3, respondents had a hard time answering this question. A general impression is 


that the vendor most often manages this access. 


If access is managed by IP and a proxy server: 


10. What is the proxy server software? (n=46) 
EZ Proxy 15 33% 
Squid 8 17% 
Web Access Management (III) 6 13% 
Netscape iPlanet Proxy 3 6% 
Microsoft Proxy 1 2% 
Other 13 28% 


Please explain 
The other software most often mentioned was Apache. Muffin and custom solutions were also 
mentioned. 


If access is managed by an ILS using 239.50: 


11, Which ILS does your institution use? (n=26) 


Endeavor 5 19% 
Ill 5 19% 
CIRSI 4 15% 
DRA 3 12% 
ExLibris 2 7% 
NOTIS 1 4% 
Other 6 23% 


Please explain 
Other ILS vendors include: GEAC, California Digital Library, and EpixTech. 
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If access is managed by passwords and user IDs: 


12. 


13. 


14. 


How are passwords and IDs generated? (n=43) 


In general, passwords are randomly generated. 


How often are they expired? (n=40) 


In many cases, passwords expire when the individual leaves the institution. In some cases, they 
expire at a set time, such as the end of the quarter, semester, term, or year. 


What security measures are used to insure that passwords and IDs are not distributed to ineligible 
users? (n=37) 


The majority of respondents indicated that staff checks an institutional or other valid ID before 
assigning a password to a user. Often, users are then required to sign a form that describes how 
passwords are to be used and what sanctions are possible for misuse. In cases where passwords are 
placed on a website, the user has to enter ID information similar to the in-person verification before 
they can access the file. 


If access is managed by a library gateway such as WebZ: 


15. 


16. 


Which gateway software does your institution use? (n=13) 


WebZ 3 23% 
Launcher 0 0% 
Other 10 77% 


Please explain 
Other responses include: a webscript from OCLC, DRA Web2, VTLS, WebVoyage, and Voyager. 
Does the gateway provide access to both Z39.50 and non-Z39.50 resources? (n=12) 


Yes 5 42% 
No 7 58% 


If access is managed by digital certificates: 


17. 
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Which system does your institution use? (n=5) 


Kerberos and VeriSign were the two systems mentioned. 


ERIC 


Future Plans 


18. 


Does your institution plan to switch to a different access management system within the next two 
years? (n=47) 


Yes 22 47% 
No 25 53% 


If yes, please identify the proposed new system. (n=22) 


EZproxy, digital certificates, and LDAP were most often identified, those most respondents appear 
to be in the planning stage and have not decided on the next system. 
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User Authentication 


Responding Institutions 


University of Alabama 
University of Alberta 

Boston College 

Brigham Young University 
University of British Columbia 
University of California—Davis 
University of California—Irvine 


University of California—Riverside 
University of California-San Diego 
Canada Institute for Scientific and Technical 


‘Information 

University of Colorado 
Colorado State University 
University of Connecticut 
Cornell University 
Dartmouth College 

Duke University 
University of Florida 
University of Guelph 
University of Hawaii 
Indiana University 
University of Iowa 

Johns Hopkins University 
University of Kentucky 
Laval University 

Library of Congress 
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Louisiana State University 

McMaster University 

University of Manitoba 

University of Massachusetts 
Massachusetts Institute of Technology 
Michigan State University 

University of Minnesota 

University of Nebraska-Lincoln 
University of New Mexico 

University of North Carolina 
University of Oklahoma 

University of Oregon 

Purdue University 

University of Rochester 

State University of New York at Albany 
State University of New York at Buffalo 
University of Tennessee 

University of Virginia 

Virginia Tech 

University of Washington 

Washington State University 
Washington University 

University of Waterloo 

Wayne State University 

University of Western Ontario 

York University 


22 


22 


REPRESENTATIVE 
DOCUMENTS 


%, Q) OFFICE OF LEADERSHIP AND 


ASSOCIATION OF RESEARCH LIBRARIES MANAGEMENT SERVICES 


O 
StS 23 


SPEC Kit 267 


User Authentication 


Explanations for Users 
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UNIVERSITY OF ALBERTA 


http://www. library.ualberta.ca/remote/index.cfm 


ave 


)) University of Alberta Libraries 
p [ e-Journals 


: Francais 
Text Version 


Subject 


Services 


Location: Home > Remote Access Wednesday December 12, 2001 


Off Campus Access. to Electronic Library Resources 


Many of the resources on the University of Alberta Library website require anyone 
using an internet service provider other than the University of Alberta or the U of 
A/TELUS modem pools to "authenticate" themselves through the University of 
Alberta Proxy Server prior to usage. 


(For example, if you are connecting to the internet via CompuSmart, Shaw, 
TELUS ADSL, SprintNet, OANet or other similar internet service providers, you will 
have to use the proxy server.) 


Additional Help 


The University of Alberta Proxy Server is a service of Computing and Network 
Services. If you need help configuring the proxy server, please contact the CNS 


Help Desk. 


If you would like to speak with a HelpDesk consultant in person, please phone 


492-9400, stop by Room 302, GSB or E-Mail the HelpDesk. 


To access a web-based resource using the proxy server, 
users must configure their web browser as outlined on the 
browser-specific pages listed below. "Re-authentication" is 
required every thirty minutes. 


®@® Instructions for Netscape 4.x 


Instructions for Netscape 3.x 


Instructions for Internet Explorer 4.x (Telephone 
Modem/56 K or slower) 


@ Instructions for Internet Explorer 4.x (High Speed 
Cable or ADSL connections) 


@ Instructions for Internet Explorer 5.x (Telephone 
Modem/56 K or slower) 
@ Instructions for Internet Explorer 5.x (High Speed 


Cable or ADSL connections) 


® Instructions for Macintosh Users 


Learning Systems | University of Alberta | Index | Sitemap | Contact_us | 
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UNIVERSITY OF CALIFORNIA—DAVIS 


http://www.lib.ucdavis.edu/libinfo/computers /proxy /index.htm] 


Access to UC Davis Licensed Resources LIBRARY 
Using a non-UC Davis (includes DSL providers) Internet Service Provider el [] 
La 


For UC Davis faculty, students, and staff only who have a UCD Login ID and password. 
(If you use a UC Davis network address, you DO NOT need to use the proxy server.) 


Instructions for setting up your browser to use the proxy: 


Best configuration for using the library's proxy server: 


Netscape: version 4.77 
IE: version 5.5 with service pack 1 + May 24 security patch 


Please Note: 


Some resources may not function properly when accessed through the proxy server. A list of these resources is 
maintained. If you experience problems with a particular resource, please check the list. 


Connecting through AOL: you will need to use Netscape as your browser while using the UC Davis Proxy Server. 

If you are using an Internet Service Provider (ISP) that uses a firewall, please contact your ISP systems administrator to determine 
how best to connect to the UC Davis General Library proxy server. If your ISP systems administrator would like to consult the 
library's proxy server specialist, please call (530) 752-1202 or emai! techhelp. 

NOTE: Specific cache settings are required for IE and Netscape. 

Make sure that your browser is set to verify documents every time, and that the cache is cleared. 

Before you can use the proxy server from your web browser, you must have a UCD LoginID and password. The proxy server 


authenticates users before acting as their agent. so you will be asked for your UCD LoginID and password whenever your browser 
accesses a resource through the proxy server. 
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UNIVERSITY OF CALIFORNIA—DaAvIS 


Important steps to complete! 


If you do not have a UCD LoginID, use the instructions found at http://mothra.ucdavis.edu/services/ . To get further 
help in setting up access, faculty and staff should contact their departmental Technical Support Coordinators (TSCs); 


students should contact IT Express at 754-HELP. 


If you do not know whether you have a-valid UCD LoginID. follow the instructions on the web-based Mothra 


Services Menu at https://mothra.ucdavis.edu/services/. 


If you have forgotten your password, go to IT Express in Shields Library in person with a picture ID to change it. 


UC Davis Medical Center personnel: if you do not have a UCD LoginID or have questions about using the proxy, 
contact Rick Lawler (rick.lawler@ucdmc.ucdavis.edu) or Neil Knoblock (neil.knoblock @ ucdmc.ucdavis.edu) in 
UCDMC Information Services. 


Warning: 


Once you have established a proxy configuration for your browser, every URL that you select will be checked first 
with the proxy. If there are network difficulties in reaching the proxy, you may not be able to connect to any URL. 
When this happens, you will need to disable the use of the proxy by your browser. 


Questions, Problems? 


If you have questions or experience problems using the Library's proxy service, please contact a reference librarian. 


What is a web proxy server? 


A proxy server is used as an intermediary between a web browser requesting a URL and the server that stores the 
URLs of restricted access resources. Valid users of domain restricted material using non-UC Davis networks, must 
configure their browsers to use the proxy service (see instructions above). Whenever such users attempt to retrieve 
restricted resources, the proxy server acts as an agent, retrieving the material and then re-transmitting it to the user. 
The proxy server authenticates users before acting as their agent. Currently, this authentication relies on the campus 
Kerberos service. 


More information can be found in the IT Times article "Electronic Library Resources Now Available Anywhere.” 


a @ a a | a | | a a a a a 
Library Home | Catalogs | Collections | Services | Help 
Search | UC Davis Home Page 


The University Library (530)752-1202 
University of California, Davis, 100 N.W. Quad, Davis CA 95616 


, send comments to Web Design Teum 
Page last updated 6 August. 2001. 
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UNIVERSITY OF CALIFORNIA—IRVINE 


http://www .lib.uci.edu/internet/remote.html 


The UCI Libraries University of California, Irvine 
FHomey ANTPAC[COLMEL| Hours Search [New Resources A.Z] Resources by Subj or Call | Services| Aboutfinternt 


fi Connecting from home: remote access guide (UCI students, faculty, and staff only) 


Choose an option below to have access to all U(|_Libraries licensed resources: 


@ ISP users - UCI Proxy Server -- more detailed instructions 


© Access to UCI Libraries licensed resources for those using a non-UCI Internet Service Provider such as Cox@Home, 
AOL, or Earthlink 
© UCInetID and password required 
© One time only web browser proxy configuration needed 
@ ZOTnet -- more detailed instructions 
© Low cost Internet Service Provider only for UCI 
© UCInetID and password required 
© No web browser proxy configuration needed to use UCI Libraries licensed resources 
® UCI LifeLine Modem Service -- more detailed instructions 


© Limited (time constraints), free dial-up access to the UCI campus network and the Internet. Not intended for more 
than modest needs. 

© UCInetID and password required 

© No web browser proxy configuration needed to use UCI Libraries licensed resources 


@ CDL/MELVYL® passwords (alternative for remote access to CDL-hosted databases purchased by UCI Libraries) 


ISP users - UCI Proxy Server 


Enables access to UCI Libraries licensed resources for those using a non-UCI Internet Service Provider such as Cox@Home, 
AOL, or Earthlink. UCI LifeLine Modem Service and Zotnet users do not need to use the Proxy Server. 


1, You must have an active UCInetID to use the UCI Proxy Server. Activate your UCInetID by following the instructions on the 


Network & Academic Computing Services (NACS) page, http://www.nacs.uci,edu/ucinetid/index.html. 


Configure your browser following the instructions on the NACS page, http://www. uci. elp/prox 
After you configure your browser, return to the UCI Libraries Web site and click on the names of the UCI resources you wish 


to access. 
. If prompted, enter your UCInetID and password. You will be connected to all resources as though you were on campus. 
. More information on the UCI Proxy Server is available at the NACS page, http://www.nacs.uci.edu/help/proxy/. 


® See - CDL passwords for an alternative to the UCI Proxy Server for access to CDL-hosted databases purchased by UCI 
Libraries. 
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ZOTnet Internet Service 


ZOTnet is a custom tailored, low cost Internet Access Service provided by zNET Internet Services for UCI students, faculty, 
and staff exclusively. 


1. You must have an active UCInetID to subscribe to ZOTnet. Activate your UCInetID online by following the instructions on 
the Network & Academic Computing Services (NACS) page, http://www.nacs.uci.edu/ucinetid/index.html. 

2, Connect thru ZOTnet. For more information on ZOTnet and how to subscribe, see - http://www.zotnet.net/, or contact 
OAC (949) 824-6116. 

3. Return to the Libraries Web site and you will be able to access resources as though you were on campus. 


®@ See - CDL_passwords for an alternative to ZOTnet for access to CDL-hosted databases purchased by UCI Libraries. 
UCI LifeLine Modem Service 


Limited (time constraints), free dial-up access to the UCI campus network and the Internet. Not intended for more than 
modest needs. 


1. You must have an active UCInetID to use the UCI LifeLine Modem Service. Activate your UCInetID online by following the 
instructions on the Network & Academic Computing Services (NACS) page, http://www.nacs,uci.edu/ucinetid/index.html. 


2. Connect thru the modem service following the instructions on OAC's page, 


http://www.nacs.uci.edu/communication/modems/. 


3. Return to the Libraries Web site and you will be able to access resources as though you were on campus. 
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@ See - CDL passwords for an alternative to the LifeLine Modem Service for access to CDL-hosted databases purchased by 
UCI Libraries. 


[top of page] 


CDL -- California Digital Library/MELVYL® passwords 
ry 


CDL/Melvyl® passwords provide an alternative for remote access to CDL-hosted databases 
(formerly called Melvyl® databases) purchased by UCI Libraries. CDL-hosted databases are 
available on the CDL/Melvyl® page. 


There are certain advantages to using a password to access these databases: 
© no need to configure your web browser 
© useful for world travellers/researchers 
© allows access from public computers at other universities or libraries 


CDL passwords allow authorized users access to the database information, but not necessarily to all 
the full-text articles linked in the database references. More information on CDL passwords is 


available at the California Digital Library. 


Passwords are available to UCI faculty, students, and staff only. You may obtain a CDL 
password at the following locations: 


Main Library: 

Multimedia Resources Center (MRC) 
Email: mrc@uci.edu 

Phone: (949) 824-7072 


Science Library: 

Interactive Learning Center (ILC) 
Email: j 

Phone: (949) 824-3680 


Medical Center Library (MCL) 


Email: mclref @uci.edu 
Phone: (714) 456-5585 


UCI -- This resource is available to UCI users only 


On-campus access: 
© UCI Libraries licensed resources are available from any computer with a direct Ethernet connection to the UCI 
network (i.e., any computer with a UCI IP address) including computers in the UCI Libraries and in campus buildings 
and offices. 


Off-campus access via: 


© ISP users - UCI Proxy Server 
© ZotNet 
© LifeLine Modem Service 
Authentication with a valid UCInetID is necessary to use these services. 
(Non-UCI users are not permitted remote access to these databases due to licensing agreements with the resource providers.) 


CDL-Hosted Databases purchased by UCI Libraries may also be accessed from off-campus by UCI faculty, students, and 
staff using a CDL password as an alternative. 


& -- Open to the world 


Access to this resource is unrestricted and open to all Internet users. 
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http:/ / www-libraries.colorado.edu/chi/remotestudents.html 


REMOTE ACCESS 


Remote Access to Chinook: CU-Boulder Students, Staff, 
and Faculty 


if pte 


UNIVERSITY OF COLORADO AT ECRILDER 


To use Chinook databases from off-campus, we recommend you log on using your CU IdentiKkey. However, if you are using an 
Internet Service Provider other than CU-Boulder (for example, US West, AOL, Earthlink), you must configure your web browser to 
use Our proxy server in order to gain full access to Chinook databases. Using your IdentiKey or the proxy server allows the Libraries 
to recognize that you are an authorized CU student, staff, or faculty member. 


Connecting to CHINOOK using IdentiKey and campus modem pools: 


Off-campus access to Chinook, the Libraries’ online catalog, and all gateway services (including Article Access databases) is available 
free to CU-Boulder students, faculty, and staff by dialing into the campus network via the PPP/SLIP modem pool. An IdentiKey 
password is needed to make the connection. 


1. Obtain an IdentiKey password and Internet software (if needed) from Information Technology Services (ITS). 
2. Set your modem software to dial the appropriate phone number: 

Off-campus: 303-218-8000 

Family Housing: 4-9900 


3. Configure your modem software so that it enters your campus username and IdentiKey password when a 
connection to the modem pool is made. 


4. Once connected to the campus modem pool, open a Web browser (Netscape, Internet Explorer, etc.) 


5. In the Location box, type the URL for Chinook: http://librari do.ed 


For more information about establishing a connection to the campus network from off-campus, see the Information Technology 
Services (ITS) web page at http://www.colorado.edu/ITS/docs/#comm or call the ITS Service Center at 303-735-4357. 


Connecting to CHINOOK using commercial Internet Service Providers (ISPs): 


If you are using an Internet Service Provider other than CU-Boulder (for example, US West, AOL, Earthlink), you must configure 
your web browser to use our proxy server. Using the proxy server allows the Libraries to recognize that you are an authorized 
CU-Boulder student or employee. After you configure your browser and click on a link to one of our commercial databases, you will 
be asked to complete a verification form that looks like this. Once you have completed this form, all of your Internet activity will be 
routed through our proxy address until you turn off the proxy setting on your web browser. 


Please note: 


@ Due toa limited amount of space on our proxy server, we are unable to include individual online journals available through 
Chinook. To access these journals, log on using your Identikey. This will allow full access to all online databases. 

@ Remember to de-activate the proxy when you do not need it. Otherwise your browser's response time and/or ability to reach 
other desired web sites might be affected. 

@ There has been a much higher success rate using the proxy with Netscape Navigator than with Internet Explorer. If you have 
trouble with Internet Explorer, you may want to try using Netscape Navigator. 
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UNIVERSITY OF COLORADO 


Proxy Server Configuration 
Netscape Version 3 Netscape Version 4 


1. Select Options 

2. Select Network Preferences 

3. Select the Proxies tab 

4. Enter in the Configuration location (URL): 


http:/Mibraries.colorado.edu:8080/proxy.pac 
6. Click Reload and OK 


MS Internet Explorer Version 3.02 MS Internet Explorer Version 4 


1. Select View 

2. Select Options 

3. Select the Advanced tab 

4. At the bottom of the Advanced page, click on the Automatic 
Configuration button 

5. Enter in the URL: 
http:/Mibraries.colorado.edu:8080/proxy.pac 

6. Click on Refresh then click on OK in the popup box 

7. Click on Apply then OK on the Options menu 


MS Internet Explorer Version 5 
Dial-up Modem Connection Local Area Network (LAN) connection 


1. Select Tools 
2. Select Internet Options... 
3. Select Connections 


4. In the Dial-up settings box find the icon with the name of your 


dial-up service. Click on the icon once to highlight it. 

5. Select: Settings... 

6. Check the box next to: “Automatically detect settings" 

7. Check the box next to: "Use automatic configuration script" 
8. Enter this Address: 
http:/Mibraries.colorado.edu:8080/proxy.pac 

9. Click on OK 

10. Click on OK on the Internet Options menu 


1. Select Edit from the pull-down menu at the top of the screen 
2. Select Preferences 

3. Click on the "+" to the left of the Advanced option 

4. Click on Proxies 

5. Click on the Automatic proxy configuration button 

6. Enter in the Configuration location (URL): 
http://ibraries.colorado.edu:8080/proxy.pac 

7. Click Reload and OK 


1. Select View 

2. Select Internet Options 

3. Select the Connection tab 

4. In the Automatic Configuration box clik on Configure 

5. Enter in the URL: : 
http://libraries.colorado.edu:8080/proxy.pac 

6. Click on Refresh 

7. Click on OK then OK again on the Internet Options menu 


1. Select Tools 

2. Select Internet Options... 

3. Select Connections 

4. Select : LAN Settings 

5. Check the box next to: "Use automatic configuration 


7. Click on OK 
8. Click on OK on the Internet Options menu 


Notes for AOL Users 


AOL's Web Browser will not work with our proxy server. You will need to use Netscape Navigator while connected to your AOL 


account. To install Netscape Navigator for AOL: 


1. Run the America Online Program 
2. Keyword: netscape 

3. Click on Click Here! 

4. Click on Download Netscape 


5. Follow the prompts to load and install Netscape Navigator 
6. Follow the steps listed above for setting up Netscape Version 4 


Remember to de-activate the proxy when you do not need it. Otherwise your browser's response time and/or ability to 
reach other desired web sites might be affected. 
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COLORADO STATE UNIVERSITY 


http://lib.colostate.edu/distance/proxy.html 


W, Colorado State University Libraries 
N 


Home 


Ya Library Catalog (SAGE) | Databases | Interlibrary Loan | Search the Web | Help | CSU 


Remote Access to Library Databases: Proxy Server 


Instructions 


Proxy Server campus, yOu must: 


pie lena ee 1. Tell your Web browser to use Our proxy server. 
Off-Campus 2. Be : currently enrolled CSU student or a CSU 
K employee. 
‘Access 3. Have either Netscape Navigator/Communicator 3.0 
Help or 4.x, or Microsoft Internet Explorer 4,0 or 5.0. 
Unfortunately, Netscape 6.0 and Internet Explorer 
5.5 do not work. 


Distance Users 


Some Internet Service Providers do not work with our 
proxy server. Read our notes for: 


With your Web browser configured, select a database from 


our list. You should see a login screen exactly like this. If 
not, you have not configured your browser properly. 


To use Libraries databases and electronic journals from off 


Setup Instructions. 
roub ing Wizard 
W. wser 


Download Netscape Navigator 
Stand-alone, which works with 


Our proxy server. 


w_t rOxy server w 


Content: Distance Learning Team 
Last updated: 10/30/01 


URL: http:/Nib.colostate.edu/distance/proxy.html 
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Colorado State University Libraries # Colorado State University 
E) Databases @ Interlibrary Loan ® Search the Web ® Help 


Disclaimer & Copyright Statement 
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http:/ /lib.colostate.edu/distance/proxy_explain.html 


\ , Colorado State University Libraries 
A 


Yd Library Catalog (SAGE) | Databases | Interlibrary Loan | Search the Web | 


Proxy Server 


Frequently 
Asked Questions 
Off-Campus 
Access 

_ Request 
Articles e Books 
Research at 
a Distance 


Other Libraries 


How the Proxy Server Works 


Why we use a proxy server: 


The databases provided by CSU Libraries are on the Web but are not 
free. We purchase these from companies. Our agreements with them 
limit access to CSU employees and registered students. If you are not 
on CSU's campus, the database companies do not know that you are 
affiliated with the university, so you are denied access. 


How the proxy server works: 


The proxy server is a computer in Morgan Library. Once you 
configure your web browser to use it, this is what happens... 


@ You click on a link to a database. 

@ Your computer tells the proxy server it wants to use a 
database. 

@ The proxy server asks you to give your name, CSU ID 
number, and a PIN number that you create the first time you 
are asked. 

@ The proxy server looks you up in the Libraries’ circulation 
system. 

@ If you're in the system, the proxy server acts as a mediator 
between you and the database. 

@ The database will talk to the proxy server, which it knows is on 
the CSU campus. 

@ The proxy server takes information from you, talks to the 
database, then sends information from the database back to 
you. 


Once you've logged in to the proxy server, you cannot see the rest of 
this happening. It just seems like you're talking to the database 
directly. 


Content: Distance Learning Team 
Last updated: 10/30/01 


URL: http://ib.colostate.edu/distance/proxy_explain.html 


A-Z Index 


Home 


Help | CSU 


How the proxy server works: 
(in pictures) 


@ Database access without 
the proxy server 

@ Database access with the 
proxy server 


Colorado State University Libraries Colorado State University 
Library Catalog (SAGE) @ Databases @ Interlibrary Loan @ Search the Web @ Help 


Disclaimer & Copyright Statement 
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Asked Questions 
Off-Campus 
Access 
Request 
Articles a Books 


Research at 
Distance 


Help 


Other Libraries 
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http://lib.colostate.edu/distance/noproxy.htm]l 


Without the Proxy Server 


When you're not using the proxy server, this is roughly what happens: 


AY Free Internet 
5 Sites 
We, 


LS 


Library 
Databases 


The Databases stop you. 
because they know you're 
not on campus. 


© Your computer talks freely to most sites and computers on the Internet. 
@ When you try to talk to a computer where one of the databases lives, you get turned away. 


To see what happens with the proxy server... 
Content: Distance Learning Team 


Last updated: 10/30/01 
URL: http://lib.colostate.edu/distance/noproxy.html 
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Proxy Server 


Frequently 
Asked Questions 
Off-Campus 
Access _ 

Request 
Articles a Books 


Research at 
__aDistance 


Help 


Home 


Other Libraries 
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Colorado State University Libraries 
Library Catalog (SAGE) | Databases | Interlibrary Loan | Search the Web | Help | CSU 


Home 


With the Proxy Server 


When you're using the proxy server, this is roughly what happens: 


Free Internet 
Sites 


Library 
Catabases 


a 
a ~ 
on — Proxy Server 
is ‘ ; 


“a Ser 
a. 
ae —— PR 


The proxy server sits 
between you and the 
library databases. 


@ Your computer talks freely to most sites and computers on the Internet, and the proxy sérver doesn't 


interfere. 
@ When you click on a link to a database, your computer knows it has to make a request to the proxy 


server. 
@ All communication between you and the database flows through the proxy server. 


Back to how the proxy server works. 
Content: Distance Learning Team 


Last updated: 10/30/01 
URL: http://lib.colostate.edu/distance/withproxy.html 
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http://helpdesk.uconn.edu/proxy/html/proxacct.html 


Connecticut 


1 University of University Information Technology Services 


Obtaining an account on the University of Connecticut Proxy 
Server 


Overview ry 


Proxy accounts allow access to web-based resources that are normally restricted to those using a valid UConn IP 
address (internet numeric addresses starting with 137.99). Accounts on the proxy server can be obtained by faculty, 
staff, and students at the University of Connecticut. 


If you are using an Internet Service Provider such as MSN, Earthlink, SNET, AT&T, etc., you will not be able to 
access restricted services. Using a proxy account provides a solution. 


NOTE: Proxy Services work best with Netscape Navigator/Communicator. Proprietary browsers that come bundled with certain 
Internet Service Providers (such as AOL, Compuserv & Prodigy) cannot be configured to use Proxy. Also, some versions of 


Internet Explorer cannot be configured for automatic proxy. 


Some examples of resources that are limited by IP are: 


1. Many UConn Library resources http://www .lib.uconn.edu, including Electronic Course Reserve 
http://www, lib.uconn.edu/ECR, most databases http://norman.lib.uconn.edu/NewSpirit/Databases, and electronic 
journals, http://norman.lib.uconn.edu/NewSpiri/FullText, t, due to contractual and licensing agreements. 


2. UConn Software Distribution Server (ftp.uconn.edu) http://ftp.uconn.edu through the web, due to site license 
restrictions. 


3. IBM BookManager® BookServer Library http://docs.uconn.edu/cgi-bin/bookmgr/bookmer.cmd/libra 


If your workstation is already within the UConn.edu or the Uchc.edu domain, it should not be set to use the proxy 
server. 


Workstations are in the UConn.edu or Uchc.edu domains if they are: 


1. Physically located on the University of Connecticut campuses, including Storrs, the Regional campuses, the Law 
_ School, and the Health Center. 


2. Using the UConn mainframe 


3. Using the Univ. ITS PPP Internet Service http://vm.uconn.edu/~wwwppp 
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Getting an Account 


Currently a userid and a password is required for using the proxy server. Application forms for obtaining accounts can 
be obtained in the Univ. ITS Accounts Office, in Room M001 in the Math Science Building. 


There is a single application form for faculty, students and staff, available online. It cannot be filled out electronically. It 


must be printed, and then filled out by hand. Application forms can be returned via mail, campus mail, or 


‘fax(486-4131). The Accounts Office can be reached by phone at 486-5236. 


If mailing from campus, the address is: 


Univ. ITS Accounts 
Unit 3138 


If mailing from outside campus, please use this address: 

Univ. ITS Accounts 

196 Auditorium Road, Unit 3138 

University of Connecticut 

Storrs, CT 06269-3138 

Finally, if you want to fax your completed form, please use this number: 
860-486-4131 

Forgotten passwords 


If you forget your password, you will have to contact the Accounts office, at 486-5236, in Room M001 in the Math. 
Sci. Bldg. You may be required to come in person and show identification. 


In order to access any IP restricted, web-based resources, a proxy server must be configured within your web 
browser. Instructions for setting up your browser can be obtained by clicking here. 


Go to Top 


This page is maintained by The University of Connecticut 
Information Technology Services Help Desk 
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http://www.cit.cornell.edu/kerberos/proxy/ 


Computing ot Cornelia—~— Authentication on the Web 


Proxy Server 
for Access to Library Resources from Outside Cornell 


@ What is a proxy server? 

eD d s proxy server? 
@ How to use the proxy server 

@ Frequently asked questions 

@ Troubleshootin 


What is a proxy server? 


Access to some online resources, such as the Library Gateway's periodical indexes, is limited to Cornell students, 
faculty, staff, and affiliates. Depending on how you connect to the network, you may or may not be recognized as a 
member of the Cornell community entitled to use these resources. 


The proxy server solves this problem by acting as your authorized agent: It confers with other servers (Cornell's 
Kerberos and permit servers) to verify that you are entitled to view the materials you have requested, then requests the 
materials for you. Because the proxy server has a Cornell network address (proxy.comell.edu), it is automatically 
recognized as an authorized Cornell user and so is allowed access to the materials you have requested. 


Do you need to use the proxy server? 


:, You don't need to use the proxy server if you connect to the Internet through Corel]. Cornell connections include 
BEETS direct-wired connections from campus buildings (ethernet or ResNet), or either of the Cornell dial-up services 
* (EZ-Remote or Express Lane). 


ene You do need to use the proxy server if you connect to the Internet using any other Internet service provider, such as 
suseasiybe RoadRunner. 


How to use the proxy server 


To begin using the proxy server, follow the steps listed here. Once you have everything set up, you will not need to take any special 
steps each time you need access to a restricted resource through the proxy server. Your Web browser will automatically contact the 
proxy server when it is needed. 


Note. At present it is not possible to use the proxy server with Internet Explorer on Macintosh (see note). 
You need to use Netscape on a Macintosh, or either Netscape or Internet Explorer on Windows. 


The proxy server also does not work with Netscape 6 on either Macintosh or Windows. 


1. Have Kerberos and SideCar security software installed and running on your computer. On Windows, if SideCar is running 
you'll see a key icon near your Start menu button. On Macintosh, pull down the Applications menu (upper right corner of 
your screen) to see if SideCar is running. If you don't have this software, use one of these links to get it: 

©@ Download Bear Access, including Kerberos and SideCar 
© Download Kerberos and SideCar without Bear Access 
@ More about Kerberos and SideCar 

2. Set up your web browser to use two features: cookies and automatic proxy configuration. Instructions are provided separately 

for the most popular web browsers: 
@ Netscape 
@ Internet Explorer 

3. Use your Web browser normally. 

4. When you select a restricted page, you will receive the usual Kerberos prompt for your Net ID and password, unless you 
already have an active Kerberos ticket. Your password will be encrypted by Kerberos for safe transmission over the network. 

5. You don't need to turn proxying off when you're done using library databases; you can simply leave it active all the time. Your 
browser will only use the proxy server for a very specific list of Cornell-restricted sites, while all other transactions will occur 
normally. . 

If you do want to turn this feature off for any reason, follow the same instructions linked in Step 2 to locate the window where 
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the Cornell proxy server's address is recorded, then remove the address, leaving the field blank. 
Frequently Asked Questions 


@ Who is authorized to use the CU Library Gateway? 

@ How can I use the resources on the Library Gateway ... 
© when I travel or when I use a computer without Bear Access? 
© if I don'tuse EZ-Remote as my Internet Service Provider? 
© if luse UNIX? 


Troubleshooting 


@ Proxy Server Errors (info from the Library Gateway) 

© Why can't I get into the Cornell restricted databases through the Library Gateway? 

© Ihave set up a proxy server according to instructions but it still doesn't work. What can I do? 

© When using Internet Explorer 5, I occasionally get an IP Check Failed error. What do I do? 

© While trying to enter a resource on the Gateway, I was asked for a special login and password. Is this right? 
@ Authentication and SideCar Errors (info from the Library Gateway) 

© Why doI have to occasionally use SideCar when I use a Cornell restricted database? 


© Why do! get a Proxy Authentication Error? 
© Even though I have SideCar and Bear Access running, I received the error message "Checking authorization by 


Comell NetID...failed. Check that SideCar is running on your computer and try again". What should I do? 


@ Authentication and SideCar Errors (info from the CIT HelpDesk) 


© Windows 

© Macintosh 
@ Library Gateway Computer Set-up page 
@ Library Gateway FAQ: Resolve Errors and Common Technical Questions 
@ Library Gateway Technical Problem Report Form 


OREO EOE ME HEE 
Introduction | Netscape | Internet Explorer | Technical Info 


SS 
Computing at Comell «* CIT Services * Kerberos and SideCar «# Proxy Web Server 


Last modified: October 11, 2001 
Need help? Please use the Library Gateway's i 
Comments about this web page: cit pubs@cornell.edu 
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http:/ /www.dartmouth.edu/~kerberos / 


Kerberos Authentication at Dartmouth 


This series of web pages include an explanation of how this software works, installation instructions for various hardware platforms, an 
authentication test page, hints for WWW developers and who to contact if you have trouble installing this software. You can download 
the kerberos software directly from these web pages. 


Many network services depend on being able to identify users of a system in order to limit access. For example you login to your 
electronic mailbox with a userid and password so only you can read your mail. Many databases are licensed from commercial 
publishers who require their use be restricted to a specific license holder. Kerberos authentication software enables us to restrict access 
to our licensed applications. 


The following are some examples of the applications that use this software for access: 
@ DASH card balances (Dartmouth users only) 
@ Degree audit (Dartmouth users only) 
® DCIS via the WWW (Dartmouth users only) 
® Biomedical Databases via Ovid (Dartmouth and Dartmouth-Hitchcock users) 


HINT: Always use the Testing your Installation page to verify that your Kerberos installation was done correctly. 


e How it Works 
e Install Configurations 
o Macintosh 
o Windows 95/98/2000 and Windows NT (32-bit) 
o Unix 
e Clearing your Kerberos Ticket 
e Testing your Installation 
e Problem Resolution (trouble-shooting) 
e Information for Web Page Developers 
o Using Kerberos in Perl CGIs 
o Using Kerberos to Restrict Access to a Web Page 


Additional questions? Send email to the Computing Services Helo Desk 
Last modified on 08/14/01 by MML. 


©2001 Trustees of Dartmouth College 
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http:/ /www.dartmouth.edu/~kerberos/intro.html 


Kerberos Authentication 
How it Works 


To use licensed databases from the Dartmouth web you need to install the Kerberos software on your desktop computer. The 
Kerberos software is comprised of two programs;-you'll need to install the pregrams called KClient and SideCar. 


These two software programs were developed originally at Cornell University to authenticate web page access. KClient and SideCar 
have been licensed for use at Dartmouth College and the Lahey Hitchcock Medical Center. You can obtain these programs through 
these web pages. After installation of these programs, you must restart your system to get the software running. 


KClient 


The KClient package combines your name and your computer's network address to produce an unforgeable network-wide 
authentication ticker . This electronic ticket can, in turn, prove to a remote server that you are the individual using a particular 
computer. 


SideCar listens for authentication requests from a web server. If a ticket is available (eg, if a person has already authenticated with 
KClient), SideCar simply returns the ticket. If no ticket is available, SideCar asks KClient to present the authentication dialog, and then 
sends the resulting ticket back to the requesting web server. 


This ticket is useful for a specified time, generally in the range of 5 minutes to several hours (you can set this expiration time yourself). 
After the lifetime of the ticket expires, you must re-authenticate yourself. This provides safety against someone using a ticket from a 
computer after you have stopped using it. It is important that you close your ticket, especially on a public machine or a machine that 
you share with other users. 


SideCar 


SideCar is an application that permits a WWW server CGI program to check the identity of an individual before returning a WWW 
page. SideCar listens for authentication requests from a web server. If a ticket is available (eg, if a person has already authenticated 
with KClient) SideCar simply returns the ticket. If no ticket is available, SideCar asks KClient to present the authentication dialog, and 
then sends the resulting ticket back to the requesting web server. 


| 


Back to Kerberos Authentication at Dartmouth 


Last modified on 08/23/99 by MML. 
©1999 Trustees of Dartmouth College 
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http://www.cit.duke.edu/remote_access/ 


Remote Access Options 
Connecting from off-campus 


Duke sponsored internet service options 


This program offers high-speed data communications using phone 
lines, and is recommended and supported by the OIT Help Desk. 


A Inj 
This program offers you special rates for AT&T's dial-up Internet 
services. 

Du 


The modem pooi allows traveling students, faculty, and staff who have 
an acpub account to quickly check e-mail from off-campus locations. 
Because connection time is limited to 15 minutes, Duke recommends 
connecting through a commercial ISP for other online tasks. For more 
information on alternative ISPs see below. 


Accessing Duke sites when you use a commercial Internet provider. 
To access Duke-restricted resources such as Site-License software or 
some library resources when using an ISP, you may be required to 
use OIT's proxy service. View this web site for details on setting up 
your system. 


Cable modem Internet service providers 


A cable connection lets you access Internet service via a cable 
television jack. 


Alternative Internet service providers 


OIT provides a list of other Internet service providers. OIT does not 
endorse any of these services (except Verizon DSL) -- this is just a 
starting point to help you find the service that best suits your needs. 
If you need more help, call or stop by the OIT Help Desk, 101 North 
Bldg., 684-2200. 


Questions? Send a message to help@oit. duke edu. 


Forrnone [ uarese J sre noex Psearci on] ouxe dt] 


QIT home | help desk [sitemap | search | Duke welcome page 
Maintenance Reports: OIlT web team 


URL: http://www.oit.duke.edu/remote_access/ 
Last updated: Aug 10 19:30:30 2001 
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http://www.uflib.ufl.edu/access.html 


UNIVERSITY OF 


To Library Databases Ries ers) 


George A. Smathers Libraries 


Guide To Remote Access me 


wi a Ya 
Proxy Info | “Classic” LUIS | Networked CD-ROMS | Distance Leaming | Having Problems? U.F. Libraries 


ALERT! While the UF Libraries’ Catalog and a number of other resources available on.the library web site are freely available to anyone connected to 
the Internet, many databases and E- Journals available there are governed by licenses with publishers or other commercial vendors. 
While generally anyone may use these resources within the UF Libraries, access outside the Libraries from non-UF workstations is limited to 
current UF students, faculty, and staff, and you must verify your current UF affiliation before being connected. 


_{In preparation for verifying your current UF affiliation when connecting remotely, you should: 


® Activate the library number on your Gator 1 Card. This 14-digit number beneath the barcode beginning with 200... will be required when 
dialing up any way besides using GatorLink, and may be needed from some UF workstations (if unable to connect directly). In order for the 
number to work for remote access, you must have used your card to check out a library book, or must have specifically asked for it to be | 
activated at any UF Libraries’ Circulation Desk. i i i i 


© Obtain a GatorLink account. This will enable you to dial-up to the UF for Internet services and access most library resources as if you were 
in the library. 


Remote Access Options - Licensed Library Web Resources 


From UF Workstations ||Normally you should be able to access the UF Libraries’ licensed Web resources as if you were in the 
(In campus offices, library. NOTE: Occasionally a license limits access to workstations located in one or more UF Libraries. 


dorms, 
at IFAS Centers...) 


If you find that you are unable to connect directly, it may be due to the way your local network access has 
been set up by your network administrator. Fortunately you still have two options: 


© Set up your Web browser to use the Library Proxy Connection for access. This requires an activated 
library number. 


@ Use one of the “dial- 


up” access approaches described below for people not using a UF workstation. 


Dialing up to connect to the UF Network using a GatorLink Account enables you to 
access the Internet and all of the licensed library Web databases as if you were 
working in the library. While this will often be an excellent way to gain access to 
library resources, keep in mind the fotlowing limitations: 


From Home or Other 
Non-UF Workstation 


@ If you are dialing long-distance, there will be telephone charges. 
® Your GatorLink account includes a basic amount of connect time each month; 
then charges accrue. More... 


Dial-Up 
toUF | 
GatorLink 


Getting Set Up for Access Using GatorLink 
You can register for your free Gatorlink account at the GatorLink web page or by 
going to the CSE building, Room E520. Telecommunication software is available on the 
UF software CD (which you can purchase from the Technology Hub) or by 
downloading from the UF Software site. Call (352) 392-HELP (UF Computing Help 
Desk) for more information and assistance in getting set up. 


Phone Numbers for Dialing Up to GatorLink 
955-0056 Settings: N-8-1 Baud Rate: 56kbps 
Other Dial-Up Numbers (1-800 and ISON/MPPP) NOTE: Surcharge for 800# use. 


The library proxy server is a special computer located on the UF campus that allows 
you to enter your library USERID (your 14-digit library number) and PASSWORD (UF) to 
verify your current UF affiliation. After verification, all your internet traffic passes 
through this computer (until you turn off access using the proxy). This is the only 
way that you can dial up to access many resources (e.g. Lexis-Nexis 
Academic Universe, Web of Science...) if you are not dialing up to UF using 
GatorLink. To learn how you can configure your specific Web browser, connect to 
i i ion. When not needed for accessing library 
databases, you should turn off the proxy connection to maximize your response time 
using the Web. 


Other 


Your ISP and the Library Proxy 


anaes Some Internet Service Providers (ISP) may intentionally block your browser's 
Service ability to use a proxy server, so you may wish to ask about this when 


Signing up. If you find that you are unable to access the library proxy |: 
through your ISP, you may also set up Internet access using your 
GatorLink account (see above). 


Provider (ISP) 
(AOL, BellSouth, 
IBM ICE ...) 


The following database services may normally be accessed without setting |: 
up your Web browser to go through the Library Proxy Connection. Instead, 
when trying to connect, you should simply be prompted to enter your 14 digit library 
number (no password). 
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® WebLUIS Indexes (20+ databases) 
e (In WebLUIS) 


© FirstSearch (60+ databases) - Connects to Menu 
® Eureka (15+ databases) + i 
@ Cambridge Scientific (60+ databases) 


If you are not dialing up using a telephone modem, but are instead 
connecting directly to the Internet using a high-speed access option like 
cable modem, DSL, arathernet (e.g. from some Gainesville apartment complexes), 
your options should be the same as shown immediately above in the "Other Dial-Up" 
section. This is also the case if you are visiting another University to do research, etc. 
and are connecting to the Internet using their network. 


Other Direct 
Connection 
(Cable Modem, DSL, 
Ethernet...) 


Copyright © 1999-2000 University of Florida George A. Smathers Libraries 
P.O. Box 117001 Galnesvilie, FL 32611-7001 


Send comments and/or questions about this site to 


Last Updated October 2, 2001 
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Setting Up Your Web Browser | Databases Available Using the Proxy U.F. Libraries 


Why is a Proxy Connection Needed? 

Many of the library databases and E-Journals available over the Internet are governed by licenses with publishers and other commercial vendors that 
require limiting access to current UF students, staff, or faculty (or to others who are using the resources within the Libraries). In order to enforce these 
access limits outside the Libraries, valid UF workstation addresses (IP numbers) are supplied to these vendors. When connecting from a UF workstation 
(whether in the library or not) — or dialing up to connect to UF for Internet access using GatorLink — the vendor recognizes that you should be allowed to 
use the resource without having to further verify your current UF affiliation. 


UF Workstation Connection Allowed Automatically Database Provider 
from “Known” UF Workstation 


However, when you try to connect from an “unknown" workstation address IP number (when dialing up from home, etc. using a 
commercial Internet Service Provider) you are blocked from entry by the database provider. Although some UF Libraries’ resources can be 
easily accessed by simply entering your “activated” 14 digit library number when prompted, access to others requires setting up your web browser to go 
through a Proxy Connection (a campus computer having an IP address that the database provider recognizes). After i i 

i ings, you will be prompted to enter a USERID (your 14-digit library number) and a PASSWORD (UF) to prove your current UF 
affiliation each time you log on. Then you will appear to the database provider as if you are actually at a UF workstation. 


UF Libraries’ 
Proxy Connection 
(Enter 14-digit library 


“Unknown" Workstation ; =====> Database Provider 


number to 
verify current UF 
affiliation) 


Use the Proxy Connection Only When Needed 

Once connected through the Proxy, all of your Internet activity will be routed through that workstation address (which the vendor recognizes as valid) 
until you turn off the proxy setting on your web browser. You should connect using the UF Libraries’ Proxy Connection ONLY when you want 
to use library databases. You should de-activate the use of the Proxy when you do not need it. Otherwise your browser's response 
time and/or ability to reach other desired web sites may be affected. if you are unexpectedly asked for your 14 digit library number every time 
you load your browser, then the Proxy is probably still active and needs to be deactivated unless you intend to use the restricted library databases. 


Warning! - Proxy Won't Always Work 

Some Internet Service Providers (ISP) may intentionally block your browser's ability to use a proxy server. Should you have problems accessing 
databases using the UF Proxy Connection, please contact your ISP or local network support personnel. The Library can do nothing about that. If you are 
unable to connect through your ISP, you may also have to set up access using your GatorLink account. However, if you are not dialing up from a local 
number, this will involve long distance charges. 


Library Web Services Available Using the UF Proxy Connection 


You may use the Proxy for all library databases and E-Journals -- Databases available through links in the Database Locator, the Quick Links 
AcZ page, or the E-Journals page should have now been set up to allow access using the UF Proxy Connection. NOTE: Occasionally a license fimits 
access to workstations located in one or more UF Libraries. 


The proxy is not always required — When you wish to connect to the fotlowing databases, you do NOT need to use the Proxy 
Connection. For these resources you should be prompted to simply enter your 14-digit library number (no password) at the time you enter each ; 
database service using any internet Service Provider (ISP). Although you may connect to these resources using the library proxy as well, routing these 
transactions in this way (through an intermediate computer) may result in unnecessarily slow response time. j 


© WebLUIS Indexes (20+ databases) 

e _Reserve 

© Fi (60 + Databases) | FirstSearch WITH the Proxy 
® Eureka (20 databases) + RLG Archival Resources (Separate Eureka Connection) 
e i ienti (60+ databases) 


® Uncover 


If you can't connect to a database, 


please report the problem to jib-webmaster@web_uflib.ufledu. 
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UF Proxy Setup Instructions 


Listed below are links to the Proxy Connection setup instructions for the minimum browser versions recommended. Instructions for some older versions 


may still be available, but we recommend upgrading your browser. 


Netscape 4 


Internet fae ies ten ieee 5. 


~ or have a DSL connection 


Ea EE Eee oT TTT (e.g. using a-cable-modem, ethernet service, or in a campus office.) 


internet Explorer 4 


: Because AOL's web browser does.not allow you to modify your proxy settings, you must download a different browser 
that will allow this setup. 


i Copyright© 1999-2001 University of Florida George A. Smathers Libraries 
P. O, Box 117001 Gainesville, FL 32611-7001 
Acceptable Use, Copvriaht, and Disclaimer Statement 
a Send comments and/or questions about this site to 
lib-webmaster@mail uflib, ufLedu. 
Last Updated September 7, 2001 
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Off Campus Access: A Guide to the McMaster 
Proxy Service 


Purpose of the McMaster Web Proxy Service 
© Provides access to library resources (such as e-journais) which are restricted for use by the McMaster community 
@ For current McMaster faculty, staff and students using commercial internet service providers (such as intertynx) 
@ McMaster Modem pool users do not need this service 

How To Set Up Proxy Service 


Step 1 - Apply for a Proxy IO (User name and password) 


Und uate, uate students and 

[slags waste sraduate students and 1 jpplydvoughMUGSI =i 

McMaster Faculty and Staff (Roll 1) hs bedi Main Office (ABB-132) or | 
mail canmela@ memaster.ca. : 


» —oe nd a eee form available at CIS (ABB-132). 


Staff furor 3) 

a Appointees and Affiliates: > Complete aaa | form available at CIS (ABB-132). 
sabbatical visitors, iol cng | scholars or ote: Form must be Nate Pom ae some aspen cro by a sponsor letter/email (to 
researchers carmela@memaster.ca)from a Roll 1 employee 


ee ee heae of Health Sciences Appointees and Complete application form and return with a eee letter to: 
ee ee heae Mora 


Undergraduate and Graduate Students, and Residents - Wait 24 hours for your account to be activated 


Faculty, Staff (Roll 1 and 3), Appointees and Affiliates ~ Wait for notification that your account has been activated. 
Step 3 - Configure your browser 


Step 4 - Check to make sure everything Is set up correctly 


© if you click on any of our restricted resources, a box as shown below should appear: 


© {if you don't get this box, then go back to step 3 and make sure you've done everything correctly. 
© Click Here To Test Your Proxy Setting 
Help 


Contact CIS Help Line 


Phone: (905) maeianoe cet. ctl 8:30am - 4:30pm 
Email: 


Updated: December 10, 2001 
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Help Pages e 


UNIVERSITY OF MANITOBA 
http:/ /www.umanitoba.ca/libraries / reference /help/proxy/ 
this site 


Us Index 


University of Manitoba Welcome - Contact Site How to use Search 
Libraries [ [ [ [th [ 


to UML 


I Using the Proxy Server to Access Restricted 
Databases and Web Resources 


The Libraries subscribes to a wide range of useful databases and web 
resources on behalf of current University of Manitoba faculty, staff, 
and students. To comply with our licensing agreements, access to 
most of these resources is limited to computers connected to the UM 
campus network (either directly or through the UM Modem Pool). 


To use these resources from computers which are not connected to 
the UM campus network, you must configure your Web browser to 
access them through the UML Proxy Server. The Proxy Server asks 
you to enter your Library ID Number and PIN, and then connects to 
the restricted resource on your behalf -- allowing you the same 
access privileges as computers located on campus. 


Who should use the Proxy Server? 


O Eligible users who connect to the Internet from a computer that 
is not on the UM campus network. This includes: 


Oo Computers with dial-up (modem) connections through 
Escape, MTS Sympatico, or any other Internet Service 
Provider other than the UM Modem Pool. 


oO Computers with cable modem or ADSL connections. 


oO Computers at any off-campus Jocation with direct (LAN) 
connections to the Internet. 


O Eligible users who experience "Access Denied," "Not 
Subscribed,” or similar error messages when trying to access a 
restricted library resource or database. 


Who shouldn't use the Proxy Server? 


If you are using a computer connected to the UM campus network 
(directly or through the UM Modem Pool) you should not use the 
Proxy Server. You should be able to access restricted library 
resources directly. Using the Proxy Server will only slow your 
connection, and force you to log in unnecessarily. 


How do I configure my Web browser to use the Proxy Server? 
Configuring your Web browser to use the Proxy Server is simple, but 


each one is a little different. Select your browser from the list below 
to see specific setup instructions. 


Oo Netscape Navigator or Communicator (version 4.x) 
oN vi version x or 3.x 


Oo Microsoft Internet Explorer (version 5.x) 
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Return to 


COhFL 


www @umanitoba.ca 


Oo Microsoft Internet Explor version 


Microsoft Internet Explorer 6 and Netscape Navigator 6 users 


While the proxy configuration files have not been tested with 
Microsoft Internet Explorer 6 or Netscape Navigator 6, we have some 
patrons who are using these browser versions successfully. You are 
welcome to try to configure your browser. 


For Microsoft Internet Explorer 6 use the Microsoft Internet Explorer 


5.x instructions. 


For Netscape Navigator 6 use the Netscape Navigator or 
Communicator (version 4.x) instructions. 


How do I determine my user name and password (Library ID 
Number and PIN)? 


When the Proxy Server asks you to enter a user name and 

password, it expects you to enter your Library ID Number as the 

user name, and your Library PIN as the password. See Determining 
Your User Name and Password if you aren't sure what your Library ID 

Number and PIN are. 


Note: For security reasons, the Proxy Server will not accept the 
"default" PIN as a valid password, even if it is correct. You must 
change your PIN at least once before you can use the Proxy Server. 
To learn how to change your PIN, please refer to the instructions at 


the end of the Determining Your User Name and Password page. 


hh The University of Manitoba Libraries 
YY Winnipeg, MB, Canada R3T 2N2, (204) 474-9881 
K Yo Questions or Comments? Email the WWW Developer 


© 1996-2001, University of Manitoba Libraries 


Last Updated: 16 November 2001 
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MASSACHUSETTS INSTITUTE OF TECHNOLOGY 


http://web.mit.edu/is/help/cert/quicksum.html 


Obtaining MIT Certificates: Quick Guide 


. Systems 


On this page: Introduction | What You Need Before You Start | MIT CA Certificate | 
Get Your MIT Personal Certificate | Security Settings 


Introduction From this page you can obtain Web certificates that will let you access MIT's secure 
Web services. You will need to get a set of MIT certificates for each computer you use. 


For more detailed information, especially if this is your first time to get MIT certificates, 
go to Obtaining Certificates for Accessing Secure Web Services-at MIT. If your 
situation matches any in the list below, follow that link to more information. 


@ Your personal certificate has expired. 

e@ You wish to check the expiration date on your personal certificate. 
@ You need information on setting certificate security preferences. 

e@ You are taking over a computer containing certificates fora pre 
@ You share a Macintosh or Windows computer. 


vious user. 


What You Need Before e@ Your valid MIT ID number. 
@ Your Kerberos user: and 


You Start Eudora e-mail). 
© Netscape 4.6 or up through Netscape Navigator 4.78 , the current supported 
and recommended browser at MIT, installed on each computer on which you 
are getting certificates. The MIT installation of 4.78 includes the MIT CA 
certificate (see below). Note: Instructions for configuring certificates only for 
Netscape are given in this guide. 


(same as for Athena, MITnet, or 


Athena users may get and use MIT Web certificates with Lynx, the text-based 
browser. Windows users may obtain certificates for 1 Explorer 5.5. 


If you do not have any or all of the above, go to Prerequisites to Getting MIT Web 
Certificates for details. 


em 


The MIT C A Certificate* You must have the MIT Certification Authority (MIT CA)* certificate before you can 
eee ~~. a personal certificate. If unsure about having one, see Check for the MIT CA. 


*Previously known as the "site" certificate. 


eee 


Get Your MIT Personal Your MIT personal certificate authenticates you to the secure MIT Web server. It __ 
—_—=——wreerr Oe «proves to the secure server that you are who you claim to be. The process for getting a 
Certificate personal certificate takes you through four screens of information and instructions. 
Details. : 


Note: If your personal certificate has expired, see When Personal Certificates Expire. 
To check the expiration date on your personal certificate, see Determine When Your 
Personal Certificates Expire. 


Security Settings Netscape lets you set certain certificate-related security preferences, either during the 
process of getting a site and personal certificate, or through the Security settings panels. 
For details, go to Recommended MIT Certificate Security Preferences. 


Comments shout these pages 
” Last modified: December 4, 2001 
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QUICK LINKS 


E JOURNALS E REQUEST FORMS LIST OF LIBRARIES 


CATALOG (web) CATALOG (telnet) RESERVES UNCLE E INDEXES AND DATABASES 


SEARCH / SITE MAP 


OFF-CAMPUS ACCESS VIA PROXY SERVER 


Supported Browsers 
Netscape: 


Communicator 3.x 


Communicator 4.x 


Communicator 4.5 or 


higher for Macintosh 
computers 


MS Internet Explorer: 
Internet Explorer 3.02 
Internet Explorer 4.x 


Internet Explorer 5.x 
(Dial-up Connection) 


Internet Explorer 5.x 
(Cable 
Modems/DSL/LAN) 


Internet Explorer 4.1 for 
Macintosh computers 


AOL, CompuServe, & 
MSN: 


Special Instructions for 
AOL, CompuServe. & 


MSN Users 


WebTV: 


Instructions for WebTV 
Users 


Help: 


FAQ: Frequently Asked 
Questions About Remote 
Access 


Information and Instructions 


Many of the electronic resources provided through UNC-Chapel Hill 
Libraries are licensed to be used only by current UNC-CH students, 
faculty and staff or UNC-CH affiliated AHEC faculty, staff, preceptors, 
and residents. To comply with these license agreements, access is 
often restricted to the Internet Protocol (IP) address range associated 
with the Chapel Hill campus. For students, faculty and staff wno access 
the internet through third-party internet service providers (ISPs) such as 
Bellsouth.net, Mindspring/Earthlink, AOL, and IBM, this presents a 
problem. The IP address owned by the ISP will not be recognized as a 
valid UNC-CH address and access to the licensed resource will be 
denied. To remedy this situation, UNC-CH Libraries have installed a 
proxy server. The proxy server has a valid UNC-CH IP address. If the 
user's web-browser has been configured to use the proxy server, 
access is available for almost all of the resources. 


What is a Proxy Server? 


A proxy server is a combination of software and hardware which acts 
as an intermediary between a set of users and the Internet. It allows 
authorized users to access almost all restricted electronic resources 
available through the UNC-CH library web pages from home or on the 
road. Users must configure their browser with the address of the proxy 
server to enable this option. 


What do | need to do? 


in order to be able to access restricted services from the 
UNC-Chapel Hill Libraries, you must configure your 
browser. 


Show me configuration instructions for my browser 


NOTE: 

If you choose to use MSIE 5.x, we recommend using MSIE5.5sp1 as 
the preferred release. You may download this version from 
http://www. microsoft.com/windows/IE/. 

You may download Netscape 4.x from 
http://shareware.unc.edu/index.html. 


Test Browser Functionality Check Functionality of my browser 


The above link checks your browser for cookie acceptance 
and JavaScript compatibility. It can assist in diagnosing 
basic setup problems. 


Your browser must allow cookies to complete the validation 
process. More information on cookies from Netscape and 


Microsoft. 


S1 
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Remote Access Requirements: 


@ Netscape Communicator/Navigator 3.x or higher, or Microsoft 
Internet Explorer 3.02 or higher. 
(Do not download versions of Netscape 6.x or 
Internet Explorer 6.x. Bugs have been identified in these 
versions and a patch to correct the problems is not yet 
available from the vendors.) 

@ Java and JavaScript enabled in your browser, and it must be set 
to accept cookies. These are the default settings in your browser. 
If you have disabled them, you must change your configuration 
before attempting to connect to a research database. 

@ Your browser configured to use the library's proxy server. You 
only need to configure your browser once. 
If your Intemet access is through 'a networked computer located 
on the UNC-CH campus, you do not need to reconfigure your 
browser. 


STEP 1: Determine which internet browser you are using: 


@ Open your Browser (Netscape, Explorer, etc.) 

@ Click “Help” on the browser menu on the top of the screen 

@ Click "About (name of browser)" 

@ A window will open which provides the version of the browser 
(4.0, etc.) 

@ Proceed to Step 2, "Select your browser type for configuration 
instructions” 


STEP 2: Click on the appropriate browser link to the left to display 
the reconfiguration instructions. 

NOTE: BE SURE TO PRINT OUT THESE INSTRUCTIONS 
BEFORE YOU BEGIN RECONFIGURING YOUR BROWSER 
SETTINGS!! 


Authentication: 


When selecting a restricted resource, you will be prompted to 
authenticate yourself with either your PID or your AHEC Digital Library 
username and password. You will only need to enter your PID or 
AHEC Digital Library account at the first restricted resource to be 
authorized for the entire session of the browser. 


It is not necessary to return your browser to its original settings prior to 
visiting non-UNC-CH Library resources. The autoconfiguration settings 
will determine the correct routing without any intervention on your part. 
However, if you use another proxy server in addition to the UNC-CH 
proxy server, you will need to change your proxy settings in order to use 
the different proxy server. Please consult the configuration instructions 
for your browser to relocate the UNC-CH proxy settings so that you can 
remove them. 


or | 
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UNC-CH faculty, staff and students: if you have 
questions regarding the PID system, please consult the 
University's information regarding the establishment of 


these numbers. UNC-CH Person ID Project 


AHEC staff, faculty, preceptors and residents: if you 
have questions regarding your AHEC Digital Library 
usemame and password or if you do not yet have an 
account, please see information on the AHEC Digital 
Library web site at: http://library.ncahec.net/, including the 
Documentation for new users. NOTE: It is no longer _ 
necessary to use or request a BID to login to restricted 
resources through the UNC-CH Proxy Server. 


The content of this page was adapted from Central Michigan University's 
Off-Campus Library Services web site. 


Home | Online catalogs | Resources | Library information | Services | DAS | UNC Home 


If you have any questions, problem reports, or comments please contact the UNC-CH Proxy Server Team via email. 
You may also call Library Systems (919) 962-1288 Monday-Friday 8AM-5PM, or the Davis Library Reference Desk 


(919) 962-1356. 


URL: http://proxy.lib.unc.edu/ 


This page was last updated Tuesday September 14, 2001. = 
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UNIVERSITY OF OREGON 


http://libweb.uoregon.edu/systems/proxy / 


‘tte University .of Oregon Library System 


The UO Library provides access to a number of databases and 
electronic resources for the campus community. Eligibility for 
access to a specific resource is based upon the terms of the 
licensing agreement signed by the library. Most electronic 
resources recognize authorized users based on campus IP 
(Internet) address. UO students, faculty and staff who use the 
Computing ‘s modem pool have full access to electronic 
resources offered by the library. 


CJ 

Bey Students, faculty and staff who use a non-UO Internet 
Service Provider (ISP) may now gain access to the library's 
electronic resources by using the library's proxy server. The 
proxy server, which has a UO IP address, acts as an 


intermediary between an off-campus computer and a database. 


To use the proxy server, the settings or preferences in a Web 
browser need to be modified. Students and faculty using the 
proxy server will be prompted for their name and ID when they 
select a link with restricted access. After being authenticated as 
a UO patron, the requested database allows the connection to 
be made as if the request were coming from an on-campus 
computer. 


® Modify browser preferences 


ve 


or 
> 


aD 
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University of Washingtow 


Computing and Networking 


About UW NetIDs 


Get Your UW NetID and Your UW NetID (with password) is your personal identification for using UW online resources. A 
Password UW NellID is required of everyone associated with the University of Washington who plans on using 
online central administrative and computing programs. These include Web interfaces used to: 


MisearchilpirectoriesillfReference Tools 


Affiliate Services 
@ Check your personal information (student grades and schedules, employee payroll records and 


Use your UW NetID to: benefits files). 
asain bask computing ® Access secure applications required for university administrative work (financial, payroll, and 


student databases). 
@ Set up UW email accounts with forwarding options, along with other computer services (dial-in 


Reset a forgotten 3 ; 
$ modems, lab access, research computing, and a MyUW page to customize as your personal 


password é 
portal to campus information). 
Change your UW NetID 
password Get Your UW NetID and Password now so you will have it when you need it. 
Manage your computing Why is a UW NetID necessary? 
services 


pen tyUW your personal Your UW NetID verifies who you are when you use the many UW network services. Such verification 
Wa. onan your person ensures the privacy of your personal information and restricts the use of resources to those for whom 
POF they are intended. To make access to such services more secure and consistent, the UW is consolidating 


Learn tore about UW the identifications you need to just one: the UW NetID. 


Be ae eee or make comments about the information on this page, use the Send a Question to C&C 


Choosing a good UW NetID 
and password 


List of computing services 
and links to documentation 


Computing & Communications: 
MIVERSITY OF help@cac.washington.edu 


WASHINGTON = Modified: August 2, 2001 
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Find it 


UW Libraries Cataiog 
Too 20 Databases 
Databases & Catatogs 
E-Journais 

Bv Subiect 

Reference Toois 


Get it 


Borrowing/Delivery 
Renewals 

Course Reserves 
View Your Record 


About the Libraries 


Contact Us 

Libraries & Hours 
Generali Information 
Givino to the Libraries 
Accessiblilty 


Services 

For Faculty & Staff 
For Grads 

For Underoraduates 
For Visitors 

My Gateway 


Help 
Connectino 
Startino Points 
Research Guides 
Librery Classes 


Alerts 


News 

Seotember 11 

Events & Exhibits 
Emoiovment Oooortunities 
Seriais Review Prolect 
Suzzalio Renovation 
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http:/ /www.lib.washington.edu/help/connect.html 


Connecting to the Libraries 


If you have a current UW Husky card, know your library PIN, and are trying to access our online 
resources from off-campus you can connect directly to the Proxy Server Wizard 


If you are no longer affiliated with the University, you should remove proxy service settings from 
your browser. ; 


FAQs about connecting to the Libraries’ online resources 


@ How do I connect my computer to the Internet? 

@ I tried to use one of the libraries’ databases and it asked me to log in. I entered a user 
name and password, but it didn't work. What do I do now? 

@ What do I need to use the proxy server or the proxy server wizard? 

@ What are UW-restricted databases and who can use them? 


e ny known bugs or problems i ctm 
line resources? 
@ How can I get to electronic reserve materials? 


onnection to the Libraries’ 


How do I connect my computer to the Internet? 
You can use the UW Internet Connectivity Kit (UWICK) or you can contract with a third-party 
Internet Service Provider (ISP) to connect to the Internet. Computing and Communications 

maintains a web page on Internet connectivity that provides details about each of these options. 


If you use the UWICK for Internet access you should have no problems accessing the Libraries’ 
online resources. If you use an ISP such as Earthlink or @Home you will need to configure your 
browser to use the proxy server. 


back to the top 


I tried to use one of the libraries’ databases and it asked me to log in. I entered a user 
name and password, but it didn't work. What do I do now? 


If you got a page from a database vendor such as Proquest, Gale, or WebSPIRS that asked for a 
username and password, you will need to set up your browser to use the proxy server. 


Many services offered by the UW Libraries are available only to current UW students, faculty, 
and staff. At present, most of these licensing restrictions are enforced based on the Internet 
Protocol (IP) address of the computer that you are using to access the Internet. If you are 
accessing the Internet from an off-campus computer, then your IP address would be assigned to 
you by your Internet Service Provider. 


A proxy service allows you to authenticate with the UW Libraries using your UW Libraries 
barcode and PIN, in order to gain access to UW-restnicted services from non-UW IP addresses. A 
proxy server wizard to help you configure your browser is available at 


http://www. lib.washington.edu/asp/browser/proxy.asp 


When using the proxy server, the 14-digit barcode (it starts with 29352) on the back of your 
Husky Card is your username and your library PIN is your password. Once you have correctly 
configured your browser to use the proxy server, you need to close your browser window and 
then open a new one. The first time that you try to use a UW-restricted database during an 
Internet session, you will be prompted for your username and password. After that you will not 
have to enter this information again during that session. 
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Back to the top 


eS 


What do I need to use the proxy server or the proxy server wizard? 


1. Acurrent UW Husky Card 
© On the back of the card you wili see a 14-digit number that begins with 29352. 
This number is your username when using the proxy server and proxy server 
wizard. 
2. Your Husky Card needs to be in the Libraries’ circulation system. This happens when you: 
© Use the card to check out something from a library 
© Bring your card to a circulation desk and ask that it be linked in the system 
© Use our online form to have it linked for you. This can take up to 2 days so if you 
need immediate access to the restricted resources you will need to bring your card 
to the library and have it linked in person. We cannot link barcodes over the phone. 
3. Your library PIN 
© If you don't have a PIN, you can set one up online by following the instructions on 
the View Your Record page. 
© More information about PIN management can be found at 


http://www. lib.washington.edu/services/borrow/pin.html 


Back to the top 
ee 

What are UW-restricted databases and who can use them? 

These are databases that are contractually restricted to current University of Washington faculty, 

students, and staff, or to persons physically present in the University Libraries. In most cases, this 

restriction is enforced by the vendor with an IP address check; only requests originating from 


computers on the University of Washington network (including the dialup modem pool) are 
considered valid unless the proxy server is used. 


Back to the top 
i 

Are there any known bugs or problems that might affect my connection to the libraries’ 

online resources? 

Check our Known Issues and Bugs page for information about software conflicts. 

Back top 
ama 

How can I get to electronic reserve materials? 

Reserve material, including electronic reserves, can be found in the UW Libraries online catalog. 

You can search the course reserves either by course (i.e. GEOLOGY 101) or professor's last 

name (i.e. Smith). Listings in the online catalog are in alphabetical order. 

Electronic reserves are indicated by an item named "ELECTRONIC READINGS FOR - 


Click on that item to get to a link that says "Connect to this title online”. Click on that link, then 
enter your UW NetID to bring up a list of electronic files for the class. 


libquest @ u.washington.edu 
Last modified: Friday August 03 2001 


UW Home |Gateway Home | Gateway Index| Search 


© 1999-2001 University of Washington 
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http://library.wustl.edu/about/proxy.html 
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aus ~Home @ Catalogs @ Databases @ Fall-text @ Reference @ Web Sites @ Research Help 


Proxy Setup Instructions 


If you wish to access restricted Internet resources (that is, those databases and electronic journals which 
are restricted by license or contract to current WU students, faculty, and staff) when usinga_ 
non-Washington University Internet Service Provid er, follow the instructions below. Such access works 
via a proxy service established by the WU Libraries. (If you're using your WUStL email account to 
make a PPP connection to the campus network, you don't need to use the proxy server. See access to 


restricted resources for more information.) 


You must set up your web browser for proxy service. This is a one-time setup; once you have configured 
your browser, you don't have to do it again - unless you get a new browser. 


FIRST, follow the instructions in the table below for your browser (scroll down this page to see 
instructions for Netscape, Internet Explorer, and for AOL users). If you have problems, please contact 


your Internet Service Provider or webmaster @ library.wustl.edu. 


THEN, once you have configured your browser: 


. Access the WU Libraries’ homepage, at http://library.wustl.edu/. 


1 

2. Click on the resource you want to connect to. 

3. The first time you do this each time you open your browser, you will be challenged for your 
o your WU ID number, and your PIN. (If you do not have a PIN, go to View Your Library 

to choose one.) 

. Filli if the requested information, and click on the Submit button. 

. You will be connected to the resource. You should not be challenged again for your name, ID, 
and PIN - until you close your browser, or unless you leave your connection idle for 10 minutes. 
(Your browser settings may affect timeouts and the caching of access permissions.) 


nb 


Please note: Not all databases and electronic journals are accessible via the proxy server. In some 
cases, this is due to licensing restrictions by the database vendor or journal publisher. See this list of the 
resources that are available! If there is a resource you wish to use which is denying you access, please 
send a message to webmaster @library.wustl.edu, indicating the name of the resource. We'll let you know 
if that resource can be made acessible via the proxy service or not. 


NOTE: 


@ Problems have been reported when trying to use the proxy server with Netscape 6. The problem 
has been reported to the software vendor, but the only solution at this point is to keep an older 
version of either Netscape (or IE) to use with the proxy server. [11/30/00] 

@ A serious problem with Internet Explorer 5.0 and proxy autoconfiguration has been discovered. 
[#2/16/99] Internet Explorer 5.01 is apparently working with the proxy server. [1/19/00] 
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Netscape Version 3 Netscape Version 4 . 


. select Options . select Edit 

. select Network Preferences 2. select Preferences : 

. select the Proxies tab . click on the '+' to the left of the . 

. enter in the Configuration Location Advanced option : 
(URL): . click on Proxies 


. click Reload and OK configuration button 


. select View . select View 

. select Options . select Internet Options 

. select the Advanced tab . select the Connection tab 

. at the bottom of the Advanced page, . in the Automatic configuration box 


. enter in the URL: http://spokane. wustl.edu:8080/proxy.pac 
. click on Refresh then click on OK in the . click on OK then OK again on the 


. click on Apply then OK on the Options 


MS Internet Explorer Version 5 
Dial-up Modem Connection Local Area Network (LAN) Connection 


. Select: Tools 

. Select: Internet Options... 

. Select: Connections 

. In the Dial-up settings box find the icon 


. Select: Settings... 
. Check the box next to: "Automatically 


. Check the box next to: ''Use automatic 
. enter this Address 


. click on OK 
. click on OK on the Internet Options 


MS Internet Explorer Version 6 


Detailed instructions not yet available. However, it has been reported that proxy settings should be 
put in Dial-up Settings, Settings button, Use Automatic Configuration script. Same address as 
above (http://spokane.wustl.edu:8080/proxy.pac). 


Notes for AOL Users 


. Keyword: netscape 

. click on Click Here! 

. click on Download Netscape 

. Follow the prompts to load and install Netscape Navigator 

. Follow the steps listed above for setting up Netscape Version 4 


http://spokane.wustl.edu:8080/proxy.pac . click on the Automatic proxy 5 


. enter in the Configuration Location dF 
(URL): 
http://spokane. wustl.edu:8080/proxy.pac 
. click Reload and OK 


yerwesaran 


click on the Automatic Configuration click on Configure 
button . enter this URL: 


SOE RL Ar OR BAR Te 


http://spokane.wustl.edu:8080/proxy.pac . click on Refresh 
popup box Internet Options menu 


menu 


. Select: Tools 
. Select: Internet Options... 
. Select: Connections 
. Select: LAN Settings 
. Check the box next to: "Use automatic 
configuration script" 
. enter this Address 
http://spokane. wustl.edu:8080/proxy.pac 
. click on OK 
. click on OK on the Internet Options 
configuration script" menu 


TULLE TOT SESE Se 


ai 


SAE 


with the name of your dial-up service. 
Click on the icon once to highlight it. 


PEO IE PRES SY 


detect settings" 


oom! lon MWbWNHN— 


http://spokane. wustl.edu:8080/proxy.pac 


menu 


PP OTE WET 


ceearery 


. To install Netscape Navigator for AOL: 


SSG PE 


ag 


SSL SETA SSS RESET ED ES 


Last update: Wednesday, November 28, 2001 Page maintained by webmaster@ library. wustLedu 


© 1993-2001 Washington University, St. Louis, Missouri, USA 
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Connect from Home 


TUG Proxy Service: 
Remote Access to Restricted Resources 


Who Can Use This Service? 
How to Connect to the Proxy 
1. Register with the TUG Libraries System 


2. Designate the Proxy Machine in Your Browser 
3, Login 
4. Special Considerations 


How et He 
Who Can Use This Service? 


This service provides off-campus access to resources and services available only to current students, faculty, and staff of the 
University of Guelph, the University of Waterloo and/or Wilfrid Laurier University. 


The restriction to use a database or service is imposed by the database provider or the site licence, or simply because of the nature of 
the service. These resources are accessible only from machines on campus (defined by IP domains: uwaterloo.ca, uoguelph.ca and 
wlu.ca). If you use the University's modem pool to connect to the Internet from home, your computer is considered to be on 
campus, and you do not need to use the proxy service. If you use a third party Internet service provider, you may log into the 
proxy server. It serves as a proxy machine between your off-campus computer and the restricted resources, and your request through 
the proxy will be treated as one onginating on campus. 


How to Connect to the Proxy 
1. Register with the TUG Libraries System 


Before you can use the proxy, you must have registered with TRELLIS, the automated library system connecting the library 
collections of the TriUniversity Group of Libraries. Registered users are students, faculty or staff who hold a current university ID 
card that has been validated (or activated) for use by the Library. If you have not validated (or activated) your card, you may do so in 
person at the Circulation Desk in the Library, or by self-registration. Distance education students may also register by phone or 
e-mail (see UG, UW, and WLU information pages). 


The authentication database of the proxy server is updated with information in TRELLIS by an overnight process. Therefore, you can 
only start using the proxy the day following validation of your card, although you are able to borrow library material and place 
requests in TRELLIS immediately. 

2. Designate the Proxy Machine in Your Browser 


You need to configure your browser to designate the proxy. Please see instructions to configure some versions of Internet 
Explorer and Netscape. 


Some resource providers use ‘cookies’. If you are set up to use the proxy server and still encounter a login screen from a resource 
provider (e.g., ABI/INFORM), it may be that ‘cookies’ are disabled. Make sure that "cookies" are enabled in your browser. 


Enter one of the following URLs in your Proxy designation: 


@ University of Waterloo registered users: 
http://www.tug-libraries.on.ca/proxy/uwproxy.pac 


.© University of Guelph registered users: 
http://www.tug-libraries.on.ca/proxy/ugproxy.pac 


® Wilfrid Laurier University registered users: 
http://www.tug-libraries.on.ca/proxy/wluproxy.pac 


Use of the wrong .pac file will not allow you to access the restricted resources of the other TUG Libraries. Authentication is based on 
your registered University affiliation. 
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If your machine has firewall protection, as some company or public machines do, the Web browser may have already had a 
designated proxy; you will not be able to access the TUG proxy service. You may discuss the problem with your systems 
administrator. 


The browser may seem to be slower when working with the proxy, since the requests are sent to the resource providers through the 
proxy server. 


3. Login 
For each session you use the Internet browser to connect to the Library, you will be asked to login with the proxy only once, when 
you first start requesting a restricted resource or service. If you have subsequent requests of these resources or services in the same 
session, you do not need to login again. 
The login process requires that you enter: 

@ User Name: Use the bar code number on your library card 

(no space in-between numbers) 
@ Password: Use your last name (lower case) 


Warning: If you sign onto the proxy machine from a shared or public computer on which you are able to designate the proxy, you 
should close the Web browser after you finish, to prevent non-legitimate use of these resources or services in your name. 


4. Special Considerations 
AOL subscribers: 

© Dial up and login to AOL as usual. 

@ Minimize the browser used to connect to AOL. 

@ Configure Netscape for the Library Proxy Service 
Netscape: 


© Netscape is free and is available at the Netscape web site. Netscape Communicator 4.78 is proven to be easy to configure for 
use with the Proxy Service. 


How to Get Help 


If you need any additional information, please contact the Information Desk in the Library. If you encounter any problem using the 
TUG Proxy Service, fill out the Problem Report form, and we will try to contact you within one working day. 


SS 
Last Updated: 2000.11.10 
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How the Proxy Web Server Works 


Currently web browsers connect directly to the remote vendors’ sites, which are site-locked to allow access only from Cornell IP 
addresses. 


A. 


Client.c ornell.edu remote.!ocked.com 
1) http: ¢remote. locked com 


2) html document 


Using automatic proxy configuration and a JavaScript file called a proxy auto-config (or pac ) file, we can configure off-site browsers 
to access the locked sites through a proxy server but contact other sites directly. 


Sample pac file: 


function FindProxyForURL(url,host) 
{ 
if (localHostOrDomainls (host, "remote. locked.com") ) 
return "PROXY proxy.cit.cornell.edu"; 
else 
return "DIRECT"; 
} 


With mee pac file, transactions to locked sites go through the proxy server (Figure B) but other transactions use a direct connection 
(Figure C). 


B. 
chert. offsite net proxy .comell.edu remote locked. com 


10) http //remote.lo cked. com 


9) return yes or no 
8) is document in cache 
proxy.comelledu 


permit server 


4) send ne tid ticket 
kerberos 
7)retum y P 
ies retum yes or no permit 


3) get netid ticket for proxy eerier 


6) checkp ermit for netid 


kerberos .at.comell.e du 
= permit! at.comell. edu 


CORNELL UNIVERSITY 


Cc. 
clientoffsite.net remote.nolock.com 
4) http:Jremote.nolockcom 


2) htm! document 


This same pac file works properly with on-campus web servers that use SideCar to authenticate their transactions. It sends the 
transaction directly to the campus server instead of through the proxy server (Figure D). 


D. 


chent. offsite net server.comelle du 


Sidecar 


' 


Call to 
permit server 


kerberos .at.comell.edu By crock peer for neue — 
permit! .at.comell.edu 


For more information, see: 


: How Does Proxying Work? from the University of Pennsylvania Library 
@ What is Automatic Proxy Configuration (APC)? 


? from the University of Pennsylvania Library 


0 O99 099449 G24 
Introduction | Netscape | Intemet Explorer | Technical Info 


LS 
Computing at Comell <* CIT Services «* Kerberos and SideCar «* Proxy Web Server 


Last modified: October 19, 2000 
Need help? Please use the Library Gateway's 
Comments about this web page: cit_ pubs @cornelLedu 
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Serveur Mandataire 


Techniques utilisées lors de la programmation 


Schema 


Un programme PERL, proxy.pl, se trouve au coeur du serveur Mandataire de la 
Bibliotheque de l'Université Laval. Ce programme, de fabrication maison, permet, a 
I'heure actuelle, une navigation passablement sans accroc sur une majorité de sites Web. 
Mais avec la constante évolution des technologies de diffusion de |'information sur le Web, 
il va sans dire que le programme devra, dans l'avenir, étre adapté pour faire face a la 
musique. Cela signifie donc qu'une veille technologique devra étre faite et qu'une certaine 
expertise en programmation CGI en PERL devra étre maintenue afin de conserver un 
serveur Mandataire fiable. 


Afin de répondre plus efficacement a ce besoin, ce manuel contient tous les détails 
techniques qu'il faut connaitre au sujet du serveur Mandataire ainsi que des 
commentaires et des trucs utiles au programmeur qui aura la tache de garder le serveur a 
jour. 


Le serveur Mandataire se veut un intermédiaire entre l'ordinateur du client et les serveurs 
Web. I! effectue la requéte HTTP que le client lui envoie et lui retoume la réponse du 
serveur. On ne peut pas se servir du serveur Mandataire sans appeler le script proxy.pl. 
Quand le client a appelé le script pour la premiére fois, on dit qu'il est en « mode proxy », 
c'est-a-dire que le serveur Mandataire prend maintenant le contréle de toutes les requétes 
que le client effectuera. I! faut s'authentifier auprés du service Portail pour que le 
navigateur client puisse appeler le script proxy.p! une premiére fois. Aprés identification a 
l'aide du numéro de dossier (code zébré) et du NIP, Portail effectue la premiére requéte 
au serveur Mandataire en spécifiant qu'il faut initialiser la session de travail. Le serveur 
Mandataire retourne alors un fichier HTML qui définit deux cadres. Le premier cadre est 
une sorte de bandeau qui contient des boutons de navigation et qui fait savoir au client 
qu'il vient de commencer la navigation en « mode proxy ». Le second cadre est la fenétre 
de navigation principale, elle contient le résultat de la requéte que le client a fait avant 
d’étre amene au service Portail. 


Comme le serveur Mandataire n'est pas un serveur « canal », c'est a dire qu'il n'exécutera 
pas automatiquement toutes les requétes du client (exemple: MS Proxy 2.0 est un 
serveur « canal», une fois le numéro IP du serveur configuré dans les options du 
navigateur client, il se chargera automatiquement de toutes les requétes), il a fallu mettre 
au point une fagon de garder le client en « mode proxy ». C’est le coeur du systéme. 


La méthode envisagée avait déja été mise au point par des spécialistes du langage 
PERL. Le serveur Mandataire a donc été bati a partir d'un programme existant. Cette 
méthode est assez simple : changer tous les liens (URL) du fichier HTML contenu dans la 
réponse du serveur afin qu'ils pointent vers le serveur Mandataire lui-méme 


(présentement, http://proxy.bibl.ulaval.ca/cgi-bin/proxy.pl) au lieu de pointer vers le 
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document original. Pour que le serveur Mandataire sache quel était le document original 
et puisse aller le chercher pour le client, on lui greffe en paramétre au nouveau lien l'URL 
Original rendu absolu. Si ce document est, par exemple, http:/Avwww.bibl.ulaval.ca/ Le 
nouveau lien devient alors : 


http://proxy.bibl.ulaval.ca/cgi- 
bin/proxy.pl?adresse=http://www.bibl.ulaval.ca/ 


On a donc passé, via le parameétre adresse, le URL absolu de la ressource demandée. 
Pour rendre cet URL absolu, une fonction du module Perl URI::URL a été utilisé. C'est 
donc en modifiant tous les URL d'un fichier HTML de cette fagon qu'on peut garder un 


Requéte modifiée Requéte originale 


Client 
HTML modifié HTML original 


e Figure : flot d'information 


utilisateur en mode proxy. La figure précédente resume cette facgon de faire. 


Définition des parametres 


En plus de l'adresse de la ressource originale, proxy.pl| accepte plusieurs autres 
parametres. Par exemple, le code zébré de l'utilisateur sera conservé et repassé a proxy 
a chaque requéte. Voici donc la liste de tous les paramétres que proxy accepte : 


Paramétre Définition 


L'URL d'une ressource. 


Le numéro de dossier (code zébré) de I'utilisateur qui fait la 
requéte. 


Opérateur booléen. Donner Ia valeur 0 a parse demande a 
proxy de renvoyer le fichier HTML sans modifier les liens. 
Par défaut, parse vaut 1, donc les liens sont modifiés. On 
verra l'utilite de ce parametre un plus tard. 


proxyframes Opérateur booléen. Pour commander a proxy de 
construire les frames de base de la navigation, on lui 
donne la valeur 1. Utile seulement lors de la premiere 
proxy. Par défaut, proxyframes vaut 0. 
Proxymenu Opérateur booléen. Si proxymenu vaut 1, proxy va 
simplement envoyer le bandeau de navigation. Par défaut, 
proxymenu a une valeur de 0. 


e Tableau : liste des paramétres 
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La sécurité du serveur Mandataire peut étre vue en deux volets. Le volet utilisateur et le 
volet ressources. Pour ce qui est de Iutilisateur, l'enjeu est de savoir si le serveur 
Mandataire a affaire a un utilisateur qui s'est authentifie auprés de Portail. Du cété des 
ressources, il faut s'assurer que le serveur Mandataire est utilisé aux fins pour lesquelles 
on |'a mis en place. Il ne faut pas oublier qu’au départ, le serveur Mandataire va servir a 
nos membres pour interroger les banques de données de la Bibliotheque a distance. 


Les utilisateurs authentifiés 


Lorsqu'un utilisateur désire interroger une banque et se trouve en dehors du campus (a la 
maison, par ligne PPP d'un foumisseur commercial, par exemple), il est amené devant 
Portail. Portail est un systéme d'authentification déja en place a la Bibliothéque qui vérifie 
dans la base de données institutionnelle la validité du code a barres et du NIP. Quand 
l'utilisateur s'est identifie auprés de Portail, Portail va porter le code a barre de cet 
utilisateur dans un fichier d'utilisateurs authentifiés. Ce fichier posséde physiquement le 
chemin suivant : E:\proxy\usagers.txt. Le programme proxy.pl est ensuite appelé pour la 
premiére fois en spécifiant l'adresse de la ressource que I'utilisateur a originalement 
demandée, le numéro de dossier de |'utilisateur et le paramétre proxyframes avec la 
valeur 1. Prenons comme ressource originale Current Contents et comme numéro de 
dossier 012345678. Techniquement, Portail effectue une requéte HTTP de l'adresse 
suivante : 


http: //proxy.bibl.ulaval.ca/cgi- 


bin/proxy.pl?adresse=http: //www.bibl .ulaval.ca/cc&codebarre=0 
12345678 &proxyframes=1 


Le serveur Mandataire, lui, une fois appelé, va vérifier dans le fichier usagers.txt afin de 
savoir si l'utilisateur s'est bel et bien authentifié auprés de Portail. Comme dans notre 
exemple, I'usager possédant le code a barres 012345678 s'est identifié avec succes, le 
serveur Mandataire va effectuer la requéte auprés du serveur Web de la bibliothéque pour 
obtenir la page d'accueil de Current Contents, va modifier les liens dans le fichier HTML et 
va retoumer le tout, au navigateur Web de l'utilisateur, formatté avec des cadres puisque 
le paramétre proxyframes a été passé avec la valeur 1. 


Apres un délai de 3 heures, un autre programme Perl, menage_usager_proxy.pl, va 
effacer le numéro de dossier du fichier usagers.txt. Aprés quoi, l'utilisateur devra retoumer 
S'identifier auprés de Portail, sans quoi, le serveur Mandataire lui refusera la navigation. 


Les ressources disponibles par le serveur Mandataire 


En plus de verifier l'identité des utilisateurs, Le serveur Mandataire posséde un 
mécanisme de contrdle des URL demandés. Ces URL sont classés dans trois 
catégories : 

1) Les URL permis 

2) Les URL défendus 
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3) Les URL strictement défendus 


A la premiére catégorie se rattache un fichier texte, comme dans le cas des usagers, 
E:\proxy\ur_proxy.tt. Ce fichier contient simplement l'adresse IP numérique ou 
alphanumérique des serveurs auxquels le serveur Mandataire peut faire des requétes. 
Par exemple, si on désire permettre aux utilisateurs de consulter le site Web de la 
Bibliotheque en « mode proxy », il suffit d’ajouter les lignes suivantes dans le fichier 
un_proxy. txt : 


# Bibliothéque de L’Université Laval 
www.bibl.ulaval.ca 


A noter que les lignes qui débutent par le caractére « # » sont considérées comme 
contenant des commentaires et ne sont donc pas traitées par le serveur Mandataire. 


ll est possible de permettre la navigation 4 un domaine entier : 


# Université Laval au complet 
ulaval.ca 


ulaval.ca peut aussi se traduire par 132.203, qui est le domaine IP de l'Université : 


# Tous les numéros IP de 1’Université Laval 
132.203 


Le fichier url_proxy.txt est donc composé des adresses de toutes les pages Web 
particuliéres, de tous les serveurs et de tous les domaines qu'on désire permettre aux 
utilisateurs de visiter en « mode proxy ». 


La seconde catégorie est dépendante de la premiére. Les adresses qui sont défendues 
sont simplement toutes les adresses qui ne sont pas dans le fichier url_proxy.btt. Il est 
important de noter que lorsqu’on appelle le serveur Mandataire avec une adresse 
défendue, il n’affichera pas un message d’erreur, il ira chercher le fichier HTML mais ne 
modifiera pas les liens. Il se comportera donc comme si on I'avait appelé avec le 
parametre parse a 0. Cela implique que la poursuite de la navigation ne se fera plus par 
lintermédiaire du serveur Mandataire, et c'est tant mieux, parce qu'il ne faudrait pas que le 
serveur Mandataire devienne un serveur de navigation Web anonyme. 


ll faut aussi savoir que cette maniére de fonctionner n'est pas totalement sécuritaire et 
qu'elle permet tout de méme a un utilisateur futé de naviguer de maniére anonyme. 
Comme on le sait, on peut appeler le serveur Mandataire en lui spécifiant une adresse et 
un numéro de dossier en paramétre. Un usager patient, mais qui désire garder l'anonymat 
sur un site en particulier, qui ne fait pas partie du fichier des adresses permises, peut 
simplement appeler le serveur Mandataire avec les URL originaux au lieu de cliquer sur 
les liens dans son navigateur Web. A chaque fois il obtiendra la ressource non modifiée, 
mais il lui suffira de répéter la procédure pour naviguer en « mode proxy » n'importe ou. Il 
s'agit la du principal inconvénient dans le fait de ne pas afficher un message d’erreur 
quand une ressource défendue est demandée, mais c’est aussi un compromis qu'il faut 
faire pour ne pas trop ennuyer les utilisateurs qui se servent du serveur Mandataire avec 
des buts plus légitimes. 
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La troisiéme catégorie va permettre de corriger un peu la faille de sécurité que la seconde 
crée. Les adresses strictement défendues se _ retrouvent dans le __ fichier 
E:\proxy\url_noproxy.txt. Si le serveur Mandataire rencontre un URL qui contient l'adresse 
d'une ressource strictement défendue, il affichera un message d’erreur et n'effectuera pas 
la requéte. Il peut étre trés pratique d'intégrer a ce fichier les adresses des sites ou des 
pages Web particuliéres dont on ne doit absolument pas donner accés, méme si on ne 
modifie pas les liens. Pensons a Chemical Abstracts, banque pour laquelle la Bibliotheque 
posséde une licence qui ne lui permet pas de diffuser en dehors du campus. Comme le 
lien vers Chemical Abstracts appelle directement le plugin Metaframe, il ne faut pas du 
tout faire la requéte car dans ce cas, ce n'est pas une page HTML qui est appelée mais 
bien une application qui s‘exécute, il faut donc bloquer l'accés directement. 


On ajoute une ligne dans url_noproxy.txt tout comme dans url_proxy.txt : 
# Chemical Abstracts, accés interdit pas proxy 
www2.bibl.ulaval.ca/bd/chemabs/ 

C'est donc grace a ces deux dispositifs de sécurité qu’il est possible de contréler les accés 


au serveur Mandataire. Evidemment, comme les besoins évoluent, il sera peut-étre utile a 
l'avenir de renforcer ces dispositifs. 


Le fichier LOG 


Le fichier LOG est un moyen de verifier qui a utilisé le serveur Mandataire, quand et pour 
accéder a quelle ressource. Les informations relatives a un accés se retrouvent toutes sur 
la méme ligne, présentée ainsi : 


JJJ_MMM DD_HH:MM:SS_<Navigateur>_<Adresse IP du client>_<URL 
demande> 


Le caractére souligné représente ici un espace. JJJ est I'abréviation du jour de la semaine 
en anglais sur 3 caractéres, MMM est l'abréviation du nom du mois en anglais sur 3 
caractéres et DD représente la date actuelle, sur 2 chiffres. HH:MM:SS représente l'heure 
en heures, en minutes et en secondes. 


Le fichier LOG pourra étre trés utile pour retracer des utilisateurs un peu trop futés ou plus 
prosaiquement pour créer des statistiques d'utilisation. 


Exception 


Afin de faciliter les tests et de donner une porte d'entrée facile au programmeur, le code a 
barre 111111111 peut-étre utilisé pour naviguer en « mode proxy ». En effet, le serveur 
Mandataire va permettre de naviguer avec ce code si I'utilisateur se trouve dans le 
domaine 132.203. Il est donc nécessaire de se trouver sur le campus pour accéder a au 
serveur Mandataire de cette maniére. Il est aussi recommandé de changer souvent ce 
code a barre de tests directement dans le script proxy.pl pour qu'il ne tombe pas entre les 
mains de n‘importe qui. 
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L'interface utilisateur est relativement simple. A la base, il s'agit de la méme interface que 

_ l'utilisateur a I'habitude de rencontrer quand il navigue sur le Web, soit linterface offerte 
par son navigateur Web. A cela, on a ajouté une sorte de bandeau, qui est en fait un 
cadre créé lors du premier accés au serveur Mandataire, aprés authentification auprés de 
Portail. Dans le second cadre, c'est-a-dire sous le bandeau, se fera la navigation Web en 
« mode proxy ». A chaque fois que l'utilisateur clic sur un lien, c'est dans ce cadre que la 
ressource lui sera présentée. 


Le bandeau contient de l'information et des icénes. Pour que I'utilisateur sache qu'il est 
bien en train d’accéder a des ressources via notre serveur Mandataire, nous |'en 
informons. Dans le bandeau, on a inscrit : « NAVIGATION EN MODE PROXY » a 
gauche. 


Dans |'extrémité droite du bandeau, on a inséré trois icénes. Le premier représente une 
petite maison. Un clic sur cet icéne chargera la page d'accueil de la Bibliotheque dans le 
cadre de navigation principal. Le second icéne est un point d'interrogation. Un clic sur cet 
icéne chargera une page d'aide dans le cadre de navigation principal. Le troisieme icéne 
représente un panneau de signalisation arrét. Un clic sur cet icOne provoquera la fin de la 
session de travail et le serveur Mandataire signalera a |'utilisateur que la navigation en 
« mode proxy» est terminée. Le serveur Mandataire enlévera le code a barre de 
futilisateur du fichier usagers.txt et l'utilisateur devra donc retoumer devant Portail s'il 
désire recommencer a naviguer en « mode proxy ». Evidemment, il n'est pas nécessaire 
de se débrancher du serveur Mandataire de cette maniére puisque la session sera 
automatiquement terminée apres trois heures, mais il est neanmoins recommandé de le 
faire. 


Le code source du script proxy.pl, lignes a lignes 


Afin de rendre facile l'ajout ou la modification de code dans le script proxy.pl, voici une 
description du programme lignes par lignes. 


21 a 23 : Message d'erreur standard qui sera utilisé a toutes les sauces dans le 
programme. 


25 a 29 : Déclaration des modules a utiliser dans le programme 
31 & 39 : Déclaration de plusieurs variables qui seront utiles pendant I'exécution. 


41 : Création d'un objet CGI. Cet objet va contenir, entre autre, les paramétres passés a 
proxy. pl. 


42 : Récupération des noms des parametres dans le tableau @in. 


43 a 48 : Sauvegarde des paramétres dans deux variables spéciales pour utilisation 
ulterieure pendant l'exécution. Le tableau référentiel %in (en anglais, Hash Table) 
contiendra les parametres sous la forme de paires clé-valeur. Pour obtenir la valeur du 
parametre adresse , par exemple, il s'agira de le référencer de cette maniére - 
Sin{‘adresse’}. La deuxiéme maniére de sauvegarder les paramétres est de créer un 
tableau de références plat. En fait, il ne s‘agit que de modifier chacune des entrées de 
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@in en lui concaténant le symbole « = » et la valeur du paramétre. En anglais, on peut 
appeler cette construction un Flat Hash. L’entrée correspondant au paramétre adresse, 
par exemple, va ressembler a ceci : adresse=http:/Avww.bibl.ulaval.ca/. Cette maniére de 
sauvegarder les paramétres va étre utile quand on voudra reconstruire les paramétres de 
la requéte originale dans une nouvelle requéte GET. 


50 a 59: Ce bout de code vérifie que la requéte provient de Portail. Dans ce cas, proxy 
ajoute le code a barre dans le fichier usagers.txt. Une ligne est aussi ajoutée dans le 
fichier LOG. Cette procédure est une faille dans la sécurité de proxy, mais aussitét que 
possible, elle sera transférée dans le programme portail pour éliminer la faille. 


62 et 63 : On conserve dans des variables l’'adresse IP du client et le type de navigateur - 
du client. 


65 et 66 : Récupération dans deux tableaux de la liste des URL permis et des URL 
strictement défendus. Ils seront utiles plus tard quand on voudra comparer avec I'URL 


demande. 


56 a 64 : Lecture du paramétre adresse. S'il n'y a pas d'adresse de définie dans les 
paramétres, la navigation proxy débute sur le site Web de la Bibliothéque 
http:/Avww.bibl.ulaval.ca/. On élimine adresse des paraméetres car lors de la reconstruction 
de la requéte originale, on veut envoyer au serveur seulement les paramétres originaux 
de la requéte. La fonction delete, qui sert a enlever un élément d'un tableau référentiel, est 
utilisée pour ce faire. A noter que s'il y a des espaces dans I’adresse, ils sont remplacés 
par le symbole « + ». 


66 a 69 : Ecriture d'une entrée au fichier LOG. Le fichier LOG est ouvert en mode ajout 
afin que la nouvelle entrée soit ajoutée a toutes les autres entrées déja existantes, sur une 
nouvelle ligne. La fonction &dateetheure va formatter l'heure et la date correctement pour 
les insérer dans la ligne a écrire. Voir la section 2.3 pour une description détaillée du 
fichier LOG. 


71 a 78 : On vérifie s'il y a un code a barres dans les paramétres. S'il n'y a pas de code a 
barres, l'accés a Proxy est refusé. Tout comme le paraméetre adresse le code a barre est 
enlevé du tableau référentiel des paramétres avec la fonction delete. 


80 a 87 : Vérification du paramétre parse. Pour une description du paramétre parse, voir 
la section 1.1. Parse est aussi enlevé des paramétres avec la commande delete. Dans le 
cas ou parse ne ferait pas partie des parametres, on lui donne la valeur 1, afin que la 
ressource soit modifiée. 


89 et 90 : On appelle la fonction &Verif_Usager qui vérifie si le code a barre est bien dans 
le fichier usagers.txt. S'il ne s'y trouve pas, on bloque l'accés a proxy et on envoie un 
message d’erreur. 


92 a 94 : On vérifie avec la fonction &Verif_URL si l'adresse demandée correspond a une 
entrée de la liste des adresses strictement défendues. Si c'est le cas, on bloque l'accés et 
on envoie un message d’erreur. 


95 a 101 : S’exécute si la &fonction Verif_URL nous indique que l'adresse ne correspond 
a aucune entrée du fichier des adresse permises. Dans ce cas, une requéte est effectuée, 
mais aucune modification n’est apportée a la ressource demandée, seul un élément 
HTML est ajouté, il s’agit de <base>, afin que les images du fichier HTML retoumé 
s'affichent correctement. La commande exit(1) termine ensuite le processus. 
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103 a 111 : On récupére le paramétre proxyframes. Sil a la valeur 1, on envoie les frames 
au navigateur client et on termine le processus avec exit(1). A noter que lattribut src de 
élément représentant le premier cadre (le bandeau) est une référence a proxy.pl avec le 

_ paramétre proxymenu a 1. Ainsi, une fois proxy appelé avec ce paramétre, les lignes 113 
a 121 afficheront le menu dans ce cadre. L’attribut src du second cadre contient un appel 
a proxy.pl avec en paramétre l'adresse de la ressource demandée. Le paramétre 
proxyframes est enlevé avec la fonction delete s'il vaut 0. 


113 a 121 : Vérification du paramétre proxymenu. S’il vaut 1, on envoie le menu Proxy au 
navigateur client et on termine le processus avec exit(1). S’il vaut 0, on enléve proxymenu 
des paramétres avec la fonction delete. 


123 : Aprés toutes les vérifications précédentes, on peut finalement exécuter la requéte 
pour le client. Les détails de la fonction &Requete sont expliqués de la ligne 168 a 260. 


125 a 130 : On détermine le URL de base de la ressource qui a été récupérée par la 
requéte de la ligne 123. Il a fallu inclure un cas spécial: IBM Patent Server. Le serveur 
envoie un header Location incorrect contenant index.html. Le URL de base ne serait donc 
pas valide. Il faut corriger cette erreur du site Web de IBM afin que les images s'‘affichent 
correctement et que les liens modifiés soient valides. Si jamais I'URL de ce serveur 
change, il ne faudra pas oublier de changer ce bout de code en méme temps. 


132 : A partir d'ici commence le traitement principal de la requéte effectuée. La ligne 132 
vérifie si la ressource est bien un fichier HTML et si le paramétre parse vaut bien 1. 
L'affirmative nous améne a la ligne 133, dans le cas contraire, nous aboutirons a la ligne 
152. 


133 a 140 : On vérifie si la réecupération du fichier HTML s'est effectuée avec succés, on 
envoie les headers de la requéte au navigateur client et on crée un objet MyFilter qui va 
effectuer les modifications au contenu du fichier HTML et les envoyer au navigateur client. 
La ligne 136 indique a Perl qu'il y a du code de défini aprés le marqueur__ END__ de la 
ligne 410, sans quoi la classe MyFilter ne serait pas prise en compte par I'interpréteur 
Perl. La ligne 137 crée l'objet MyFilter en lui assignant la valeur des variables $BASE, qui 
contient l'adresse de base de la requéte, $ajout, qui contient l'adresse de proxy et 
$codebarre. La ligne 138 et 139 activent l'objet MyFilter avec le contenu du fichier 
temporaire contenant le code HTML de la ressource. Ce fichier est créé par la fonction 
&Requete. 


141 a 150 : On arrive ici si la requéte n’a pas été effectuée avec succés. Dans ce cas, il 
peut se produire deux choses : lignes 142 a 146, le code d’erreur associé a la requéte est 
302, il s'agit d'une redirection qui n’a pas été traitée. Dans ce cas il faut simplement 
modifier le header Location pour qu'il pointe vers Proxy, ainsi, le navigateur va récupérer 
la bonne ressource. Lignes 147 a 149, le programme ne gére pas lerreur qui s'est 
produite et envoie simplement un message d'erreur au navigateur client. Aux fins de 
déboguage, la ligne 148 affiche le code d’erreur et le message d’erreur dans le 
navigateur. 


152 a 154 : On antve ici dans le cas d'une ressource autre qu’un fichier HTML ou si le 
paramétre parse a été passé avec la valeur 0. On envoie tout simplement la ressource 
originale au navigateur client. 


156 et 157 : On détruit les fichiers temporaires créés durant le processus. 


159 : Le programme se termine avec succés. 
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168 : Fonction &Requete. 
170 : Récupération de la méthode passée en argument. 
171 : Création d'un objet UserAgent, qui va effectuer la requéte HTTP. 


173 : Vérifie si on a affaire a une méthode GET. Dans ce cas, les lignes 174 a 198 sont 
exécutées, sinon, la ligne 199 vérifie si on a affaire 4 une méthode POST, si c'est le cas, 
ce sont les lignes 200 a 222 sont exécutées, sinon, Proxy a été appelé avec une méthode 
qui n'est pas gérée et on envoie un message d’erreur au navigateur client. 


174 a 184 : Reconstruction des paramétres de la requéte. Pour ce faire, on utilise le Flat 
Hash. On débute la chaine de paramétres $query_string par un « ? », on ajoute ensuite 
chacun des paramétres différents d’adresse et de codebarre, suivi du caractére « & ». Les 
lignes 181 a 183 vérifient sila chaine de paramétres ne contient que le « ? », dans ce cas 
la chaine ne contient pas de paramétres, on lui assigne une chaine vide. 


185 a 187 : Vérifie simplement que la chaine de paramétres ne se termine pas par un « & 
», dans ce cas, on l'enléve parce que ¢a signifierait envoyer un paramétre vide avec une 
valeur vide, ce qui n’est pas souhaitable. 


188 : Création d'un nouvel objet Request, qui contiendra toutes les informations au sujet 
de notre requéte. On lui assigne dés le départ l’'adresse de la ressource demandée ainsi 
que la chaine de paramétres reconstruite aux lignes 174 a 187. 


189 : Initialise le header User-Agent de la requéte avec le type de navigateur du client. 


190 : On informe aussi l'objet UserAgent du type de navigateur client afin que le serveur 
sache a quel genre de navigateur il a affaire. 


191 : Comme il faut conserver les cookies de la requéte au cas ou le serveur nous les 
demanderais, cette ligne crée un objet Cookie qui stockera les biscuits dans le fichier 
cookies.txt. A remarquer qu'il est important d’assigner la valeur 1 a l'argument 
ignore_discard pour que tous les cookies soient conservés, méme ceux que le serveur ne 
désire pas que nous conservions. Si on ne le fait pas, les cookies habituellement 
conservés en mémoire vive par Netscape seront perdus et certaines requétes seraient 
alors faites hors contexte, ce qui pourrait avoir des effets bizarres. 


192 : On informe l'objet UserAgent qu'il a maintenant une jarre a biscuits a sa disposition. 
193 : Et que cette jarre a biscuits se trouve dans le fichier cookies.txt. 

194 : Al'objet Request, on greffe les cookies trouvés dans la jarre qui lui sont pertinents. 
195 : Et aprés tous ces préparatifs, on effectue finalement la requéte. A noter ici que l'on 
n'a pas besoin de créer un objet Response. Cet objet est automatiquement crée par le 
UserAgent et retoumé dans la variable Sres. 

196 et 197 : Les cookies regus sont extraits et rangés dans la jarre. 


199 : Vérifie si on a affaire 4 une requéte POST. 


200 : Vérifie si le type d’encodage des paramétres est multipart/form-data. Dans ce cas, 
exécute les lignes 201 a 205, sinon les lignes 206 a 221. 
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201 : Requiert les services du module HTTP::Request::Common qui est en mesure de 
traiter les parametres multipart. 


202 : Cette ligne effectue une opération étrange, elle transforme le tableau de références 
%in en variable référentielle a un Hash. Cette étape est par contre essentielle parce que 
c'est sous cette forme que les paramétres seront passés a la requéte. 


203 et 204 : On effectue la requéte sans gérer les cookies. II serait préférable de le faire, 
mais comme le probleme est assez complexe, il n'a pas encore été résolu. A faire dans 
un avenir proche. A noter la maniére dont on initialise les différents headers de la requéte, 
dont on passe les paraméetres et dont on assigne I'adresse de la ressource dans le cas 
d'un objet HTTP::Request::Common. Tout se fait dans la méme instruction. 


206 : Le type d’encodage n'est pas multipart, on suppose donc qu'il s'agit de www-form- 
urlencoded, le type d’encodage par défaut. 


207 : Crée l'objet Request et lui assigne l'adresse de la ressource. Les paramétres seront 
passés ultérieurement. 


208 : Initialise le header Content-Type avec le type d’encodage utlisé. 
209 : Crée un objet URL de type HTTP. 


210 : A cet objet URL, on greffe les paramétres de la requéte contenus dans le tableau 
référentiel %in. 


211 : Les paramétres aboutissent finalement dans le contenu de la requéte. Pour les 
passer a l'objet Request, on utilise la méthode equery de l'objet URL qui « escape » les 
caractére non-ascii et les caractére spéciaux contenus dans les paraméetres. 


212 a 220 : idem aux lignes 189 a 197. 


223 a 225 : On a appelé Proxy avec une méthode non gérée, un message d’erreur est 
envoyé au navigateur client. 


227 a 229 : Sauvegarde les headers de la réponse dans un fichier temporaire. 


231 a 237 : Vérifie le type mime de la réponse et la sauvegarde dans une variable. Si les 
headers de la réponse ne contenaient pas de type mime, on lui donne text/html par 
défaut. Cette opération est importante puisqu’il faut savoir si on doit modifier le contenu de 
la ressource. 


239 a 243 : On enléve les headers X-Meta et Content-Length des headers qui seront 
retoumés au navigateur. C'est pour éviter justement que le header Content-Length ne 
contiennent une valeur erronée aprés modification de la ressource. 


245 a 250 : Sauvegarde le contenu de la réponse dans un fichier temporaire qui sera 
utilisé par la suite. A noter les lignes 247 et 248 qui ajoutent des marqueurs de 
commentaires quand il y a des scripts dans le fichier HTML. 


252 a 260 : Demiére partie de la fonction &Requete qui vérifie s'il ya un header META 
avec l'instruction REFRESH dans le fichier HTML. Si c'est le cas, la fonction &Requete 
devient réentrante jusqu’a ce qu'il n'y ai plus de REFRESH 4 traiter. ATTENTION : cette 
partie du programme est peut-étre dangereuse. Je ne I'ai pas testée en profondeur et il 
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est possible que le programme entre dans une boucle sans fin si jamais le REFRESH 
pointe toujours vers le méme fichier. C’est a verifier. 


268 a 289 : La fonction &Print_Frames qui génére le fichier HTML des frames de la 
navigation en mode Proxy. 


297 a 321 : La fonction &Print_Menu qui génére le fichier HTML du menu de Proxy. 

329 : La fonction &Lire_URL. 

330 : Récupére le nom du fichier a lire des arguments. 

331 : Tableau temporaire qui va contenir la liste des URL. 

332 a 339 : Lecture du fichier et stockage de la liste des URL. On stock chaque URL deux 
fois : une fois sous sa forme originale et une fois sous sa forme « escape ». Ceci est du au 
fait que l'objet MyFilter « escape » les URL originaux avant de modifier les liens dans le 
fichier HTML. Il faut donc pouvoir comparer des pommes avec des pommes et des 
oranges avec des oranges. A noter la ligne 334 qui élimine les lignes débutant par « # ». 
Ces lignes ne sont que des commentaires dans le fichier. 


341 : On retoume le tableau contenant tous les URL lus. 


350 a 360 : Fonction &Verif_URL qui vérifie si l'adresse de la requéte correspond a une 
des entrées du tableau des URL passé en argument. Retoume 1 si c'est positif, 0 dans le 
cas négatif. 


368 : Fonction &Verif_Usager. 
369 : Récupére le nom du fichier des usagers et le code a barres a verifier. 
370 : On définit un tableau temporaire et l'opérateur booléen. 


371 a 377 : Lecture des codes a barres contenus dans le fichier des usagers authentifiés, 
stockage dans le tableau temporaire. 


378 et 379 : Vérifie si le code a barres 111111111 est utilisé. Dans ce cas, r'usager est 
valide si l'adresse du client fait partie du domaine 132.203. 


380 a 383 : Si on trouve le code a barres dans le fichier des usagers authentifiés, I'usager 
est valide. 


384 : On retoume l'opérateur booléen qui vaut 1 quand I'usager est valide et 0 s’il est 
invalide. 


393 a 408 : La fonction &dateetheure qui imprime simplement la date et l'heure dans le 
fichier LOG. La ligne 394 initialise la structure localtime avec la date et I'heure présente, 
les lignes 395 a 401 récupérent chacun des éléments de la structure dans des variables 
plus faciles a reconnaitre et les lignes 402 a 407 impriment la date formatée comme on le 
désire. Bogue de I'an 2000, hé oui, on ne peut y échapper : si l'année est < que 2000, il 
faut ajouter le 19... (sinon la date ne s'afficherait que sur 2 caractéres : 99 par exemple). 


410 : Marqueur de fin du programme. Dépassé cette ligne, rien n’est interprété si on ne le 
spécifie pas dans le programme. 
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419 : Début de la nouvelle classe MyFilter, dérivée de HTML::Filter. Cette nouvelle classe 
a été modelée a partir d'un programme de Randal L. Schwartz disponible a I'URL : 
http:/Awww.stonehenge.com/merlyn/WebTechniques/col32.html 


420 a 422 : Modules qui contiennent certaines méthodes qui seront utiles. 
425 et 426 : Ces lignes étaient la et n'ont pas été modifiées. 
428 et 429 : 4 variables globales a l'objet et qui seront utiles. 


431 a 438 : Hash des éléments qui contiennent des URL qui devront étre modifiés pour 
pointer vers Proxy. 


440 a 447 : Hash des éléments qui contiennent des URL qui devront simplement devenir 
absolus. 


449 a 463 : Ce bout de code transforme chacun des Hash en Flat Hash. C'est un tour de 
passe-passe assez complexe qu'il n'est pas nécessaire d’expliquer. 


465 a 472 : a la création de l'objet, on définit trois choses : $self->{Uri} qui est en fait 
l'adresse de base de la ressource, $self->{ScriptName} qui contient la valeur de. la 
variable $ajout définie au tout début du programme et $self->{CodeBarre} qui est le code 
a barres de l'utilisateur authentifié. 


475 a 478 : Ces quelques lignes n'ont pas été modifiées du programme original et ne 
devraient pas avoir besoin de I’étre parce qu'on ne désire pas modifier les déclarations, 
les commentaires et les Zones de texte dans le fichier HTML. 


480 a 493: La méthode end qui est appelée quand I'objet MyFilter rencontre un élément 
de fermeture HTML. Si I'élement </FORM> est rencontré, il faut ajouter deux champs 
<HIDDEN> au formulaire. Ces champs contiennent I'adresse originale de I'attribut action 
du formulaire qui a été remplacé par l'adresse de Proxy et le code a barres de I'utilisateur 
authentifié. Il est extreémement important d’ajouter ces deux champs parce que lorsque le 
formulaire sera envoyé, Proxy va le recevoir et doit connaitre I'URL original ainsi que le 
code a barres de l'utilisateur afin de pouvoir effectuer la requéte correctement. Si jamais le 
fichier HTML contient un élément de départ <FORM> mais pas d’élément de fermeture 
</FORM> (et ¢a peut arriver, mauvais codage HTML par I'auteur!!), il faut quand méme 
insérer les 2 champs <HIDDEN>. Les lignes 286 a 491 voient dans ce cas a les insérer et 
corrigent méme le code HTML en lui ajoutant I’élement de fermeture </FORM>. 


495 : La méthode start. C’est le coeur de l'objet MyFilter. C’est ici que la modification des 
URL se fait dans les éléments HTML de départ. A chaque fois qu'un élément de départ 
est rencontré dans le fichier HTML cette méthode est appelée. Nous n’allons traiter que 
les éléments stockés dans les Flat Hash construits a la ligne 449. 


496 : Le premier argument envoyé a une méthode d'un objet est en général le pointeur a 
cet objet. On le récupére avec la fonction shift, qui sans argument va s'appliquer a la 
variable @_, tableau qui contient tous les arguments passés. Shift ramasse l’argument et 
l'enléve du tableau, comme si on faisait un pop sur une pile. 
497 Récupére les 4 prochains arguments dans 4 variables. 


498 Définition de deux variables qui seront utiles. 
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499 a 501 : Construction d'une table de caractére d’échappement qui va permettre d’ « 
escaper » l'adresse de la ressource qu'on va placer en paramétre de proxy.pl dans les 
URL modifiés. D'habitude on se sert de la méthode uri_escape du module URI::URL pour 
ce faire, mais étrangement, ¢a entre en conflit avec notre nouvelle classe dans ce cas-ci. 


502 : On commence a réécrire I'élement HTML en imprimant < et le nom de |'élément 
contenu dans Stag. 


503 : Pour chacun des attributs de I'élément, on exécute les lignes 504 a 541. 
504 : On imprime le nom de I'attribut et le symbole « = » et un guillemet. 
505 : On se définit une variable temporaire $val qui correspond a une chaine vide. 


506 a 508 : Si la valeur de lattribut est différente de la chaine « value », on copie cette 
valeur dans $val. Cette opération est nécessaire parce que dans le code html de certains 
sites, aux attributs value de certains champs de saisie est associé une valeur « value » 
sans guillemet qui est interprétée correctement par Netscape, mais notre méthode start 
corrige le HTML et ajoute des guillemets pour chacun des attributs, aprés quoi, la valeur « 
value » entre guillemet est interprétée par Netscape littéralement et le formulaire devient 
alors incorrect. Ga peut sembler compliqué, mais si on enléve ce bout de code préventif, 
on comprend vite pourquoi il a été ajouté. 


509 a 511 : Ici on vérifie si I'élément et I’attribut font partie de la liste des éléments dont 
I'URL doit étre rendu absolu. Si c'est le cas, la ligne 510 se charge du travail. 


512 : Vérification e I'élement et de I'attribut une seconde fois. S'ils font partie de la liste des 
éléments dont I'URL doit étre entiérement réécrit, alors on va exécuter les lignes 513 a 
537. 


513: Sil'URL est un point d’ancrage (« anchor » en anglais) on ne lui touche pas. 


514 a 519 : Si c'est un appel a la fonction javascript MkUniq des pages HTML de 
Proquest Direct, on va opérer certaines modifications a I'URL passé en argument a cette 
fonction. Cette opération trés délicate est nécessaire afin que le code javascript de 
Proquest demeure opérationnel. 


520 a 522 : Si I'URL est une référence a un fichier de définition d'une image map, on le 
rend simplement absolu. 


523 a 527 : Sion a affaire a un élément <FORM> on change I'URL d’action pour URL de 
proxy. On assigne |'URL original du formulaire a la variable $adresse, qui sera utilisée 
ultérieurement pour construire un champ <HIDDEN>. 


528 a 536 : Il faut reconstruire totalement I'URL. Dans l'ordre, les morceaux du nouvel 
URL sont : L’adresse de Proxy, le paramétre adresse avec l'adresse originale de la 
ressource rendu absolu et sous forme de chaine « escapée » et le paramétre codebarre 
avec le code a barres de I'utilisateur authentifié. 


539 et 540 impriment finalement I'URL modifié, en encodant les caractére >< et & quill 
peut contenir. 


542 : Termine d'imprimer I'élément avec la caractére >. 
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543 a 546 : Si on a rencontré |'élément formulaire, il faut construire les deux champs 
<HIDDEN> qui sont imprimés a la ligne 480.. 


547 a 549 : Dans le cas de Proquest Direct seulement, on ajoute un élément <BASE> 
dans le header du fichier HTML avec le URL de base de Proquest. Ceci encore dans le 
but de permettre au javascript des pages de Proquest de fonctionner correctement. 


Statistiques 


Dans la section sur la sécurité, il a été vu que le serveur Mandataire créait un fichier LOG 
de toutes les requétes effectuées. C’est a partir de ce fichier que les statistiques sont 
compilees par un script Perl appelé compile.pl. Ce programme compile les données 
ralatives au navigateur utilisé par rapport au nombre de requétes effectuées, au numéro 
IP du client par rapport au nombre de requétes effectuées, au numéro de dossier du client 
par rapport au nombre d’authentifications faites auprés du service Portail et a la ressource 
utilisée par le client a savoir s'il s'agit d'un serveur inteme a la bibliothéque ou d'un serveur 
exteme. Le fichier des statistiques compilées (statistiques. txt) ressemble a ceci : 


# Navigateurs 
Mozilla/4.0=256 

# Numéros IP 
123.123.123.123=23 

# Login usagers 
012345678=1 

# Ressource consultée 
externe=5555 
interne=5555 


Evidemment, le fichier réel contient beaucoup plus de types de navigateurs, de numéros 
IP et de numéros de dossiers différents. 


Un autre script Perl (stats_proxy.pl) permet de visionner les statistiques compilées dans 
un navigateur Web comme Netscape. Les données sont alors présentées sous forme de 
tableau pour en faciliter la lecture. On peut les consulter a l'adresse : 


http://proxy. bibl. ulaval.ca/cqi-bin/stats_proxy.pl 
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University ITS 


Authentication Project - 


“Index Welcome to i i T 


In addition to many other services, University ITS is developing 
a campus-wide authentication system that will allow a single 


@ Laiversity 1S - 


: ‘ d 
@ UConaWeh username and password to be used on most University 
[Wuconnwer services. 

Authenticati oj Profile 


The Project Profile defines the scope, phases and resource requirements of 
the Authentication project. It is a good starting point to understand how 
UConn's project is defined and how it relates to Single-Sign-On, Portals, 
email, groupware and other current issues. 


Policy issues & Frequently Asked Questions 

Part of bringing together many different information technology systems 
under a common username and password umbrella is developing policies 
that address security, privacy, management and technology issues for the 
many users. This addresses policy and provides an opportunity to comment 
on the UConn initiative. 


oiect Timeline Task Assignments 


The timeline is a working document that defines critical project milestones 
for the project. This page also shows which group is responsible for each 
project associated task. 


Research, Development, Prototyping 

As the team evaluates solutions and their integration with existing 
technologies at the University, updates are added here to document the 
research. 


To access your Lotus account on the web, click here. 
To access your Login to Exchange, click here. 


Last updated 9/3/01 
Mail comments to: Rob. Vietzke@uconn.edu 


UConn 
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Authentication Project Profile 


Project Profile 


Authentication, Authorization and Security Project 


None 
FY2001-FY2004 
June 1, 2001 


The Authentication and Authorization project is a strategic initiative of the Information 
Technology Steering Council and UITS. It is intended to reduce the number of username 
and password instances a user at the University must manage and to begin to create a 
central repository that identifies all users of IT services within the University community. 
To date, most ID management systems have been functionally related (IE: "Mainframe 
ID", "Student ID", "Staff ID", "Voicemail PIN", "PPP ID", "WebCT ID", "Exchange ID", 
"Novell ID", etc.) As the Authentication project evolves, all of these usernames and 
password instances will be consolidated under a single, and more secure, central database. 


The usefulness and acceptability of the system will be in part based on its pervasiveness 
within the community. This means that any individual who can reasonably claim 
association with any IT related system at the University will need to be offered an 
identifier on the system. The implications are that a comprehensive review of the policies 
that regulate creation, management and use of all University identifiers will be cnitical to 
the project’s long-term success and sustainability. 


Through the ITSC, it has been determined that this will be a multi-year phased effort that 
will initially focus on broad student services including email, library access, file 
storage, WebCT and calendaring . 


After the initial project infrastructure is in place, mechanisms to enable distributed 
authorization off of the central authentication system must be enabled for web based and 
possibly even legacy based applications at the departmental level. 


This project will involve a number of business practice changes throughout ITS and the 
University to be successful. By example, the format of the Universal ID (CMS ID) 
will likely need to be changed for all faculty and staff. Also, many of the 
methods through which accounts are added and deleted to various systems will 
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Program Manager: 
Telephone: 
E-mail: 


Fax: 


Project Management: 


need to be refined to allow the separation of username/password authentication 
management from role and authorization functions. 


Rob Vietzke, Chief System Architect, UITS 
(860) 486-3962 
Rob. Vietzke @ uconn.edu 


(860) 486-8425 


Rob Vietzke serves as the overall project manager, currently working approximately 40% 
on this project and drawing on staff resources that have been requested from other areas 
of UITS. This profile and previous project outlines request four dedicated UITS staff 
members , which is the consensus of project need among both internal and external 
groups that have reviewed this project profile. Once these resources are in place, one of 
the dedicated staff members will be asked to assume the role of day to day team leader. 
This individual will also be responsible for documenting project status on a weekly basis. 


The project will be divided into three phases, in each phase, prototyping, system 
development and rollout will occur . During the latter portion of one phase, a second 
phase may startup and run concurrently. 


There are three activities related to the Authentication project within UITS. 
Responsibilities included in this are: 


© Core Technical Team — Evaluate technologies and integration issues, 
prototype solutions, recommend implementation approaches. This team 
currently includes 3 members of the server support team, allocated on a 
time/availability basis up to 20%, a University Library IT staff person at 
20% and a Law Library staff person at 20%. (Additional staff to grow the 
project resources to 4 FTE have been requested as part of this and prior 
project plans.) 


© Matt Smith of the server support group is currently 
responsible for investigating, | documenting and 
recommending a relationship between Windows NT, 
Windows 2000, Active Directory, and Exchange for use in 
the LDAP environment. 


© Bruce Roy is responsible for installing the C/A LDAP 
product on top of ACF2 as a possible production LDAP 
environment -for one instance of the authentication 
mechanism. Bruce is tasked with installing the product in the 
S/390 environment and then working with Matt and Mitch 
to test the LDAP schema functionality. 


© Mitch Saba is responsible for establishing a working test 
of the WebCT environment on Solaris against an external 
LDAP authentication mechanism. Upon successful proof of 
concept for WebCT, Mitch will be working to establish a 
conversion plan for the existing WebCT environment. 
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© Peter Murvay is contributing Linux and authentication 
support to the team on behalf of the Law School. He is 
primarily working with AIX and LINUX hosts in testing 
both LDAP clients and server models. Peter will be 
responsible for testing replication between different LDAP 
servers once they are in place. 


{O) Steve Weida is responsible for assuring that the 
prototype environment in UITS would meet the needs of the 
University Libraries with regards to authenticated resources 
they may provide. Steve is also investigating the conversion 
of the electronic course reserves (ECR) onto WebCT after 
the successful conversion of WebCT authentication. 


© Policy Steering Committee - Include a broad cross-section of the 
University to determine implications and approaches to business-practice 
related policy issues. Focus is on information dissemintaiton, awareness, and 
local activities required to implement central policies. This group is chaired 
by Rob Vietzke, with Elaine David contributing major portions of the 
policy framework. 


Elaine David has been assigned to research, document and coordinate 
major policy issues related to IT and specifically this project. In her role as 
policy coordinator, she is looking for best practices related to 
Authentication at other institutions, adapting them to UConn circumstances, 
and presenting them to the technical and policy working groups for 
discussion. Upon vetting in these groups, she will be working to bring these 
issues to the ITSC for approval. 


© University ITS Leadership- Manage and coordinate work in 
functional areas to effect both core system architecture/operation 
and business practices to effect the new single username/password 
approach for the systems identified. Specifically, the leadership 
team will be responsible for coordinating efforts and investing staff 
resources to accomplish tasks throughout the project. The cross 
area work will need to be syncronized to assure timely outcomes. 


For this project to be successful, the UITS leadership will needs to 
examine and determine strategies to increase the 24 availability of 
the system and services that will serve the Authentication system. 
Examples of areas for review may include continued automation 
of account maintenance functions, network availability, server 
availability, network/server security and weekend support. 


The UITS leadership must also coordiante this project with several 
other projects that will rely on this system for their 
username/password information. Similarly, this project will depend 
on several other intitiatives to deliver the initial services requested 
by the ITSC. By example, Peoplesoft, Email, Groupware, File 
Storage/Server Consolidation, WebCT, Listserves, Network, and 
portal initiatives are all heavily intertwined with Authentication 
and must be managed together for overall cohesion and 
interoperability. 
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© University ITS Functional Areas - Throughout the process, 
resources in Network, Server, Applications, Database 
Administration, Help Desk, Operations and Device support will be 
required to make large contributions to specific portions of the 
project. The manager’s of these areas will be expected to lead the 
implementation and coordination of efforts within their areas 
under the general project leadership. 


Initial examples of work that fucntional areas in UITS may need 
to contribute to this project include: 


© Applications: Creation and support of interfaces 
from/to existing HR and Student Systems to facilitiate 
automatic creation of username/password pairs, 
syncronization of the ID database with the LDAP 
server, PIN and ID system syncronization, privacy 
policy application, and interfaces to personal name 
and list-serve systems. 


© Help Desk/Accounts: Definition and refinement of 
policies related to creating and managing 
authorization to central services, 


© Network: Creation of a highly-secure "server 
zone" within the network architecture that can safely 
allow LDAP server replication and maintenance 
within the "zone" while also allowing limited 
user-side access to LDAP lookups and other database 
queries. 


© Network: Establishment of service level 
expectations and definition of redundancies that can 
be expected for the directory server segments of the 
network 


© Server Support: Identification of a _ preferred 
platform within the UNIX domain on which the 
authentication services will run and be most fully 
supported for a production environment. 
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Project Need: The University currently has dozens of individual usemame/password and authentication 
systems spread across departments, divistons and individuals. Many individuals manage 
five Or more usemames/passwords to access the resources they use on a daily basis. The 
user angst associated with multiple identities also requires multiple administration functions 
and decreases security by removing any single point of management or policy base for 
deactivating privileges. 


The ITSC has identified this project as a critical strategic need for the University's IT 
infrastructure to move forward. 


Project Benefit: This project will enable students, administrators, and teachers to work more. productively 
across many systems at the University, without requiring individuals to maintain separate 
identities within the Community. By simplifying the number of identities maintained 
within the community, user should be able to remember a more robust set of username 
and password schemes for their single account, thus increasing security. 


As a core component of future services, the authentication system will also enhance the 
University’s ability to rapidly deploy customized services based on_ individuals. 


Project Impact: « Student, Faculty and Staff users will have a defined, 
irrevocable identity within the University Community which 
will allow distributed authorization to many separate IT 
systems. 


« The University will be able to participate in national 
middleware initiatives, allowing new collaborations of 
researchers and students across institutions. 
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Information Tech. Component One : Identity Management and Authentication 

Architecture: 
The project will be based on one or more open LDAP servers, which will hold basic user 
information like an individual’s Common Name, Preferred Name, Email Address. Street 
Address, Telephone Number, Fax Number, and Organizational Title, etc. In addition. the 
LDAP directory will hold a password and some additional authorization attribute fields for 
a limited numberof core University services_The LDAP structure will be based on the 
standard InetPerson and EduPerson object classes, perhaps with a UconnPerson attribute 
set added as well. 


To address a need to integrate with ACF-2 on the S/390 systems, licensing costs 
associated with retired identifiers, as well as allow for FERPA related student privacy 
issues, it is likely that a meta directory will be required with several primary information 
services feeding it. The metadirectory may be the publicly “exposed” server that offers 
services like departmental server authorization and web-based directories. whereas the 
directory servers below the metadirectory may carry more comprehensive base data. 


Upon initial deployment, at least one LDAP server will need to receive and resolve feeds 
from the ID System (HR and Student Systems) as well as patron feeds from the 
University libraries and potentially other sources. (The Policy working group is actively 
working to define and refine these requirements.) 


The LDAP directory will become a central depository for the identification of users 
throughout the University. Best practice at other Universities implies that as the LDAP 
infrastructure is stabilized. the UITS may choose to use the LDAP database to feed the 
legacy systems, as opposed to the other way around. In this instance, the LDAP database 
becomes the single central repository of ID information for all University community 
members. 


It is likely that subsequent phases of the project will add tributary servers for additional 
specialized authorization attributes. It is also likely that some custom programming will be 
created to integrate services like Microsoft's active directory with the open LDAP server. 


Component Two: Authorization and Services 


As the directory is developed, key technologies are also being developed to synchronize 
the LDAP based directory into system tools that can be used for authorizing individuals 
into particular services. First, links from LDAP into operating system level 
user-management systems for Windows, Novell, S/390 (ACF2), and Unix/Linux are being 
researched. Second, web-development tools to allow LDAP resources to be integrated 
into custom applications will also be researched. 


By addressing the integration of the directory into operating-system level user 
management systems, most of the applications that ride on top of contemporary operating 
systems will be able to take advantage of the underlying user management systems in the 
Operating systems. In the instance of S/390, an attempt to link LDAP to ACF2 may allow 
applications level security to be applied to the LDAP based username/password pair. 


The prototype should prove that an operating system based integration with the LDAP 


system should also create a framework for robust web-development using SSL and 
certificate systems. 
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1/2001 through 6/2003 


Phase 1 — Spring 2001 - Summer 2001 

Prototyping of. WebCT, Email, Calendaring and File Storage for students 
Longer term project scope refinement 

Identification and draft recommendations of cniical university wide policies 


Budget and resource allocation to address project needs 


Phase 2 — Falt 2001 — Spring 2002 

Creation (Replication/Conversion) of Universal ID for all Faculty and Staff 
Begin Implementation of student file storage, Web CT, Email & Calendaring 
Prototyping of integration of Authentication services with web services 


Prototyping of distributed server integration options for NT, 2000, Novell 


Phase 3 —- Summer 2002 — Falt 2002 


"Cutover" of Student accounts to Authentication system for core services ** 
(** pending budget and staff allocation, could be later.) 
"Cutover" of Faculty / Staff accounts to Authentication for core services ** 
(** pending budget and staff allocation, could be later.) 
Availability of Authentication services for centrally based web services 


Begin Implementation of distributed server support infrastructure 


The goal is to create a single repository of identities for members of the University 
community. From the single repository, central services may be both authenticated and 
authorized. The repository will also enable distributed systems to Authenticate, while 
allowing local control of authorization on distributed systems throughout the University. 


Implementation will require consolidation and conversion of existing disparate 
username/password systems throughout the institution, starting with identification and 
adoption of a single User ID standard. As the project expands, any user affiliated with the 
University who needs access to University IT resources will have to be added to the 
Authentication ID database. 
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Project Deliverables: Based on allocation of budget for this project as defined below and the Email and File 
Storage initiatives separately under consideration, we expect to meet the following 
deliverables: 


Prototype of WebCT, Email, Calendaring, File Storage Sept 15, 2001 
Communication to University Re: Universal ID Creation Sept 15, 2001 


Working environment for student services ** Dec 1, 2001 
( ** Pending Budget and staff allocation ) 


Prototype of web development environment March 1, 2002 
Prototype of Novell, NT, 2000 environment May 1, 2002 
Working environment for web development July 1, 2002 


Working environment for Novell, NT, 2000 integration Sept 15, 2002 


Organization: The University Information Technology Services will take the lead role in coordinating 
this project. Individual departments who wish to become involved in the project will need 
to also contribute both technical and functional support to the project as services in their 
areas are considered for migration into the solution. 


As user access to information becomes increasingly reliant on this system, the support of 
traditional UITS "Accounts Desk" functions into off-shift hours will become increasingly 
important. 


Costs and Funding: Including FTE Staff allocation, this project will cost $880K, $850K, and $400K for its 
three-year implementation cycle. For ongoing maintenance, FTE, licensing and other 
support costs are expected to be approximately $208K per year. 


Project Issues: The largest issues are institutional and organizational support to move this project forward 
in a timely fashion. This project's success depends on staff allocation, financial allocation 
and a broad UITS and University-wide cultural commitment to migrate current business 
practices to work cooperatively around a common identity management system. 
Significant communication by the UITS and JS senior leadership to continue to encourage 
faculty, staff and students to adopt the new system will be essential. 


The UITS leadership will need to identify the staff and funding resources to begin the 
significant work described herein immediately in order for the timelines to be met. This 
project profile will need to be updated regularly to reflect a slower implementation 
timeline if additional resources are not allocated immediately. 
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Risk Management: Network and server design to provide redundancy and security of the system databases 
will be essential. UITS will need to consider the development of a fire walled "secure" 
domain in which to house the Directory servers and key tributaries. The availability and 
reliability of the network itself to provide authentication services will also be critical. If the 
service is to be broadly adopted by users who currently maintain their own identification 
and authorization schemes, it is essential that the system is trusted to be secure and is 
nearly always available. The network and server support teams will need to become 
actively engaged in this process to assure adequate availability and security. 


User expectations already exceed available resources and as such, expectation 
management will be critical, particularly if limited resources continue to be allocated. 


Simultaneous progress and regular communication on the Student Email, Central File 
Storage and Network Upgrades will also be essential for this project to make its timelines 
and deadlines. 


University of Connecticut ITS 


PROJECT COST SUMMARY 


agency name: University of Connecticut ITS 


project name: Authentication Project 


Costs Costs Costs 
Cost category FY 2002 FY 2003 FY 2004 


4 FTE @ $60,000 4 FTE @ $60,000 4 FTE @ $60,000 


Estimated 
Annuel On-going 
Support Costs 


2 FTE @ $60,000 


plus benefits plus benefits plus benefits plus benefits 


$300,000 $300,000 $300,000 $150,000 


(including Telecom) 
TOTALS $755,000 $780,000 $397,500 $207,500 


General Fund Generel Fund Genera! Fund 


Indicate ell General Fund 


funding sources: 


Federal Fund Federal Fund Federal Fund Federal Fund 


Cepitai Capital Cepital Capital 


Other: Other : Other : Other : 
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http:/ /www.ist.uwaterloo.ca/sy/projects/idauth/ 


Identification, Authentication, and University of 
Electronic Commerce wate, 00 


2000-08-07 


1997 ID-AUTH Working Group 


1998 ID-AUTH-ECOMM Project 


? Purpose and organization 

> Objectives 

2 Stakeholders and scope 

? Plans and progress 

7 1998-07 RFI: Integration of Identification/Authentication Services on Unix and Microsoft Platforms 
be 

? 

? 


Proposal for Identification/Authentication prototype ... summary, detail 
2000-06 final report 


Maintained by Roger Watt, IST. 
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http:/ /www.ist.uwaterloo.ca/security/id-auth/final/ 


FINAL REPORT for the 
Ip-AUTH-ECOMM Prototype 
University of Waterloo 


Preface 


This document is a final report on the implementation of a Prototype for the Identification, 
Authentication and E-Commerce Project. A prototype ID-AUTH system has been 
implemented that replaces the original UWdir Institutional Directory, augments that with an 
authentication service for the campus at large and provides self service access to UWdir 
data. The prototype was put into limited production in mid November of 1999 well in 
advance of the year 2000 changeover (but well behind the original schedule). The old 
directory service is no more. 


The intent here is to fulfill the obligations undertaken in the Post Prototype Commitments -- 
an evaluation of the goals given in the Objectives of the project, an implementation review 
to address several questions and finally some recommendations on how we ought to 
proceed. 


It is emphatically not our intention to terminate our work with UWdir and the continued 
evolution of the Institutional Directory. Instead we're stopping our current work (briefly) at 
a natural milestone to examine what we've done (in case there are things we want to do 
differently -- and there are) and think a little about where we are going (with the release of 
Windows 2000 there are directions we need to consider). 


Accepted: by UCIST 23-June-2000. 


11-June-2000; (ed) Reg Quinton 
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IpD-AUTH-ECOMM Prototype 
University of Waterloo 


Introduction 
The Objectives for this project (from the 1998 Proposal) were: 


The ID-AUTH Prototype is a demonstration project with modest goals -- to 
improve existing processes and services (especially around HR/SIS and 
UWdir), to demonstrate that a central ID-AUTH service is possible and will 
work (if only for a limited set of applications), to learn some things while 
“getting our feet wet" and finally, to make recommendations about how (or 
if) we ought to proceed. Our plans are to do all of that while incurring 
minimal risk and minimal financial commitments. 


The objective of this prototype is to prove that Polaris II can use the 
ID-AUTH service established -- there is no commitment to deliver this 
ID-AUTH service to the entire Polaris community by January 1999. The 
prototype is an opportunity for Polaris II testing (in particular load stressing, 
scaling tests, etc.) so that a migration can be safely planned . 


It most definitely is not our objective to implement the perfect solution that 
solves everyone's needs -- that we believe is very difficult, very expensive 
and likely impossible. 


The Prototype has improved the processes around UWdir and especially it's relationship to 
Human Resources and Registrar's data. The implementation is far simpler than the previous 
version, data arrives in a more timely fashion, data has been extended to include 
information required to distinguish users (birth date and gender) and to include information 
that helps in managing student accounts (we now have data for students on COOP work 
terms, we have registration status to identify students who have withdrawn). Self service 
access for users lets them manage data without our intervention (their web page and email 
address). Self service access for authorized system managers lets them implement users 
without waiting for data from HR or other sources. Self service access lets these managers 
create generic listings for Departments and other role based contacts. 


The Prototype demonstrates that a central service that identifies users (with an assigned 
UWuserid) and authenticates them (with traditional password credentials implemented by an 
NT4 Domain) certainly is possible and will work to integrate several services -- traditional 
Windows login (and file mounts), controlled access to Web services (eg. UWdir itself and 
other services like the new Request Tracker within IST) and PAM aware applications (like 
login, IMAP and POP mail, etc.) on Solaris. Projects like the Electronic Voting and the 
Network Authentication Project build on the authentication service we have established. 


The "Lessons Learned" and "Recommendations" are covered in separate sections of this 
report. 


Our relationship with Waterloo Polaris is not so clear. Very early in the implementation 
Polaris developers found a Radius solution that integrated the Watstar servers with their 
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Unix authentication servers. They've come to rely on Pluggable Authentication Module 
(PAM) services on Solaris systems (using Radius) similar to our use of PAM on Solaris to 
authenticate against the NT4 Domain using Server Message Block (SMB) Protocols. While 
it's clear that the ID-AUTH prototype could have provided the Radius service that Polaris 
relies on (there are lots of Radius implementations on NT) we certainly could not have 
provided it when they needed it+- our prototype was delivered a year late (sic!). In any 
case, now that the prototype is in limited production, it's clear that Windows 2000 sets a 
direction where we acknowledge that there's no need for Radius stress tests (or the soon to 
be obsolete NT4 Domain) -- the vendor sets us on a path to Kerberos authentication. 


Finally, we acknowledge that we've not built a perfect solution that meets everyone's needs 
-- the prototype is an ID-AUTH service but it would be very presumptuous to call it the 
ID-AUTH service for the campus at large. By numbers alone the Polaris system is far more 
pervasive and mission critical. In the interim Microsoft has delivered Windows 2000 Active 
Directory and much of what we have built is now obsolete -- the NT4 Domain 
Authentication Service should be replaced by an Active Directory supporting Kerberos, 
SMB and LDAP authentication protocols; the CSO/PH Directory service should be 
replaced by the Light-Weight Directory Access Protocol (LDAP) services provided with 
Active Directory. Nevertheless we have something that will serve us well as we move 
forward to vendor solutions that implement open protocols. 


12-June-2000; (ed) Reg Quinton 
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Recommendations 


The prototype we've delivered is but one small step in the continued evolution of an 
Institutional Directory and that's a project that's been ongoing for many years. "Where to 
next?" is an important question as things will continue to evolve. Some observations and 
recommendations follow: 


1. We have agreed that the ID-AUTH Project will move towards a maintenance phase 
in the near term, with only minor changes, mostly related to improving the 
consistency and integrity of the data. During that time, partially as a result of the 
Active Directory/Windows2000 project, we will gain significant additional 
knowledge about Active Directory that may prove relevant for the future evolution 
of UWdir as an Institutional Directory. 


2. The ID-AUTH project assumes that the Active Directory/Windows2000 project will 
articulate some requirements that will be placed on future, production naming in 
both the Windows2000 and (Internet) DNS contexts. This may result in renaming 
and/or deprecating the uwaterloo.ca authentication service as it now exists (ie. the 
NT4 Domain name may change). "Authentication service" is intentional, and not the 
same as the "Identification service" on the diagram. 


3. A future phase of the ID-AUTH project should re-examine the implementation and 
underlying technologies of the "Identification service." 


‘There are many recommendations implicit in other sections of this paper -- see especially 
the Lessons Learned. The list above is a capsule summary of the larger issues that will 
shape where we go next. 
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